Re: Database "Transactions" and HTTP statelessness

Hi BP-- There's also named cursors, but then you're going to have the problem of time. That is if you create a cursor FOR UPDATE and the user never saves the record or never cancels the edit (just closes her browser, for instance), then you're messed up and have locks floundering around in the db. In the HTTP stateless scenario, you really do want to do everything within the timespan of a single page-view. Dave Watkinson's suggestion for a column in the table to store some kind of version info (a timestamp or some other identifier that is updated every time the record changes) is a good one because it makes detecting an updated row a lot easier than comparing all of the original values from the originally loaded record to what's there when you finally go to save it. However, there may be times when Dave's suggestion can be overly restrictive. Let's say User A changes one column of Record R and User B changes a different column of Record R. In that case, the changes do not step on each other and probably should be allowed. Dave's suggestion for a per-record version identifier would kick out the 2nd person to save the record's edits with the "this record has been changed by another user or process" message. Perhaps that's correct for your application, perhaps it is not. You and your customer have to decide. That's why I tend to compare the originally loaded values of the fields that have been changed by the user with the fields as they appear in the record during the transaction that UPDATEs the record. If they're different then those fields really have been modified by another user or process and the transaction should be abandoned until the user gets a chance to review the situation. Hope this helps, Doug At 12:13 PM 8/29/01 GMT, Bopolissimus Platypus wrote: >On Wed, 29 Aug 2001 03:18:01 -0400, dougslist@semig.com (Doug Semig) [--snip--] >thanks. that was one of the alternatives i'd been considering. >heh, i was trying to avoid the complexity. after all, if the database >already has locking and data consistency built-in, why reinvent >the wheel, right? but that denial of service thing is a problem >(and it would be a SELF-denial-of-service :). thanks for voting >for this alternative. i'll wait a few days for others to comment >and maybe provide alternatives before committing to one >approach :). > >tiger [--snip--] --Doug's Signature File---------------------------------------- ~ ~ ~ I'm proud to work for GLISnet, Michigan's best ISP ~ ~ ~ --1.888.445.4763---8am to 8pm every day---http://www.glis.net-- The views and opinions expressed in this email are my own and may not be those of my employer.