Re: Database "Transactions" and HTTP statelessness

On Wed, 29 Aug 2001 03:18:01 -0400, dougslist@semig.com (Doug Semig) wrote: >0. User A loads Record R. >1. User B loads Record R. >2. User B edits and saves Record R. > (Saving involves starting a transaction, retrieving R from the DB, >comparing the values with the original values to make sure it is > the same record, and then the UPDATE and then commiting the > transaction). >3. User A edits and saves Record R. > (Saving involves starting a transaction, retrieving R from the DB, >comparing the values with the original values to make sure it is > the same record, and when it's not, rolling back the transaction and > notifying the user that the record has already been modified by > another user or process). 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