Re: Same Table Opened Twice

This WebDNA talk-list message is from

2003


It keeps the original formatting.
numero = 47168
interpreted = N
texte = Here's an example, Gary.Customers can sign up for our eNewsletter on the sidebar of the store, which is a standard connection, and can also click on a link from the email to remove their name or change their email address. This process accesses a table called eNews.db. Customers can also sign up for the eNewsletter as part of their checkout process, which is a secure (SSL) process. Currently, I am not writing to the eNews.db when this occurs, as I dare not. If I do write a process that accesses the eNews.db when they complete their checkout process, it will open that table via SSL. I will then have two copies of eNews.db open in memory, with different data. Depending on in which order they eventually get closed, one data set or the other will get saved. The other will be lost. This is a problem.In Win 2000 and in OS9, this problem doesn't occur (in my experience, as things are set up on the servers I use).It's possible I can get around this problem by using [EXCLUSIVELOCK] and always closing the db when I'm done with it, but that seems unfortunate. (And I'm not sure how WebDNA handles contention; if I use [EXCLUSIVELOCK] and a second process tries to open that db, perhaps an error will be generated and data will be lost anyway.)Barring another solution, I will probably deal with this particular instance of the problem by extracting eNews signups during admin processing of orders, using a double redirect (one redirect goes to an insecure URL and writes to the eNews table; and then redirects back to the secure order processing page). I think that is also unfortunate, but it will work. However, this is just an example--there are other instances where both domains might need to write to the same table. Or someone may somehow get to the store through the secure URL (or heaven forbid to the order processing interface through the insecure URL), and things may get screwed up.Velma At 09:09 PM 01/23/03, you wrote: >I don't understand why some people would be allowed to modify the database >outside of the SSL while others cannot (or vice-versa) ? > >Or, if they all can't modify the database, then I don't understand these >terms in the context that you used it: > >accessed & write over each other > >Or, after messing with setting up an SSL certificate all day today, maybe >I'm just SSL tuckered out..... > >GK > > > > > > On my sites, the same tables are sometimes accessed through two different > > domains, one with a secure certificate and one without. > > > > In Windows 2000 and Mac OS9, this works fine. The systems know they are >the > > same table. No problem. > > > > In OSX, I get two copies of the same table opened, and they can write over > > each other, if they are tables the sites writes to. For example > > [LISTDATABASES] will show: > > /www/velma/www.communitymade.com/tables/Settings.db > > /www/secure/communitymade/tables/Settings.db > > If one could access this table through URLs, it would be accessed as: > > http://www.communitymade.com/tables/Settings.db and > > https://secure5.anu.net/communitymade/tables/Settings.db > > > > Web server is Apache, don't know the version, nor the OSX version (10 > > something) but can find out if it matters. > > > > Have others run into this? Is there a solution? I couldn't think of what >to > > search for in the archives. > > > > Velma > > >------------------------------------------------------------- >This message is sent to you because you are subscribed to > the mailing list . >To unsubscribe, E-mail to: >To switch to the DIGEST mode, E-mail to > >Web Archive of this list is at: http://webdna.smithmicro.com/---------------------------------------- Velma Kahn Glory Day Software Company 200 Tanager Ln NW, Floyd, Virginia 24091, U.S.A. phone: 540-745-6469 * fax: 651-321-4884 email: vkahn@glorydaysoftware.com http://www.glorydaysoftware.com http://www.communitymade.com http://www.floydcrafts.com ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ Associated Messages, from the most recent to the oldest:

    
  1. Re: Same Table Opened Twice (John Peacock 2003)
  2. Re: Same Table Opened Twice (Velma Kahn 2003)
  3. Re: Same Table Opened Twice (John Peacock 2003)
  4. Re: Same Table Opened Twice (Velma Kahn 2003)
  5. Re: Same Table Opened Twice (Gary Krockover 2003)
  6. Same Table Opened Twice (Velma Kahn 2003)
Here's an example, Gary.Customers can sign up for our eNewsletter on the sidebar of the store, which is a standard connection, and can also click on a link from the email to remove their name or change their email address. This process accesses a table called eNews.db. Customers can also sign up for the eNewsletter as part of their checkout process, which is a secure (SSL) process. Currently, I am not writing to the eNews.db when this occurs, as I dare not. If I do write a process that accesses the eNews.db when they complete their checkout process, it will open that table via SSL. I will then have two copies of eNews.db open in memory, with different data. Depending on in which order they eventually get closed, one data set or the other will get saved. The other will be lost. This is a problem.In Win 2000 and in OS9, this problem doesn't occur (in my experience, as things are set up on the servers I use).It's possible I can get around this problem by using [exclusivelock] and always closing the db when I'm done with it, but that seems unfortunate. (And I'm not sure how WebDNA handles contention; if I use [exclusivelock] and a second process tries to open that db, perhaps an error will be generated and data will be lost anyway.)Barring another solution, I will probably deal with this particular instance of the problem by extracting eNews signups during admin processing of orders, using a double redirect (one redirect goes to an insecure URL and writes to the eNews table; and then redirects back to the secure order processing page). I think that is also unfortunate, but it will work. However, this is just an example--there are other instances where both domains might need to write to the same table. Or someone may somehow get to the store through the secure URL (or heaven forbid to the order processing interface through the insecure URL), and things may get screwed up.Velma At 09:09 PM 01/23/03, you wrote: >I don't understand why some people would be allowed to modify the database >outside of the SSL while others cannot (or vice-versa) ? > >Or, if they all can't modify the database, then I don't understand these >terms in the context that you used it: > >accessed & write over each other > >Or, after messing with setting up an SSL certificate all day today, maybe >I'm just SSL tuckered out..... > >GK > > > > > > On my sites, the same tables are sometimes accessed through two different > > domains, one with a secure certificate and one without. > > > > In Windows 2000 and Mac OS9, this works fine. The systems know they are >the > > same table. No problem. > > > > In OSX, I get two copies of the same table opened, and they can write over > > each other, if they are tables the sites writes to. For example > > [listdatabases] will show: > > /www/velma/www.communitymade.com/tables/Settings.db > > /www/secure/communitymade/tables/Settings.db > > If one could access this table through URLs, it would be accessed as: > > http://www.communitymade.com/tables/Settings.db and > > https://secure5.anu.net/communitymade/tables/Settings.db > > > > Web server is Apache, don't know the version, nor the OSX version (10 > > something) but can find out if it matters. > > > > Have others run into this? Is there a solution? I couldn't think of what >to > > search for in the archives. > > > > Velma > > >------------------------------------------------------------- >This message is sent to you because you are subscribed to > the mailing list . >To unsubscribe, E-mail to: >To switch to the DIGEST mode, E-mail to > >Web Archive of this list is at: http://webdna.smithmicro.com/---------------------------------------- Velma Kahn Glory Day Software Company 200 Tanager Ln NW, Floyd, Virginia 24091, U.S.A. phone: 540-745-6469 * fax: 651-321-4884 email: vkahn@glorydaysoftware.com http://www.glorydaysoftware.com http://www.communitymade.com http://www.floydcrafts.com ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ Velma Kahn

DOWNLOAD WEBDNA NOW!

Top Articles:

Talk List

The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...

Related Readings:

Listserver problem (1997) WebDNA v6 & MySQL (2008) Template Encryption (1998) Re:2nd WebCatalog2 Feature Request (1996) WebCat2b15MacPlugin - showing [math] (1997) summ=T (2003) Setting up WebCatalog with Retail Pro data (1996) Requiring that certain fields be completed (1997) Up and running ... at last !! (1997) WebCat & cookies (1998) strange [date] behavior (2001) Slow wiht MAC OS and Webstar IV (2002) 2 easy questions re: [showif] and [sendmail] (1997) WebCatalog can't find database (1997) creator code (1997) GuestBook example (1997) PCS Frames (1997) Tab Charactor (1997) Database changes (1998) Here's how to kill a Butler Database. (1997)