Re: Database "Transactions" and HTTP statelessness

Hi BP-- 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). Hope this helps! Doug At 02:02 AM 8/29/01 GMT, Bopolissimus Platypus wrote: >hello all, > >I've got a question about what's got to be a common problem. >I'm sort of doing a survey to see how others have solved this >problem before so that I can choose one that's best for me. > >Basics: > The software is a web based data entry system. > Sessions are maintained (so that users don't have to > login after every database operation, and for > security - users can only perform actions that > are allowed to their login or group0. > >Use Case: >0. User A loads Record R. >1. User B loads the same Record R. >2. User B edits and saves Record R. >3. User A edits and saves Record R. > [--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.