RE: [CFCDev] [Kind of OT]: Record Locking and Avoiding Race Condi tions?

[Roland Collins]

IMO, you’re asking for trouble if you have to get users talking to resolve locking conflicts.  Irregardless of the programmatic bottleneck, you’re now introducing a “physical world” bottleneck.  And how do you think Mary feels after finally clicking “submit”, only to be told “Sorry - you’ve been hijacked”?  You’re essentially saying that whoever clicks “submit” first has the most important data!   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Balog Sent: Tuesday, February 24, 2004 11:02 AM To: '[EMAIL PROTECTED]' Subject: RE: [CFCDev] [Kind of OT]: Record Locking and Avoiding Race Condi tions?   I like the idea of user negotiated locking =)  Does your application suffer any performance hits due to the nature of the locking in the lock manager?   Thanks,   Justin -----Original Message----- From: Mark Porter [mailto:[EMAIL PROTECTED] Sent: Monday, February 23, 2004 10:39 AM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] [Kind of OT]: Record Locking and Avoiding Race Conditions? We come accross this quite a bit. The system we use is to create an application structure that is keyed off the id of the object being edited. When a user (Joe) obtains a lock, his or her userid and a timestamp is added to the structure. If another user(Mary) attempts to get a lock they are given a message similar to this: "This object was locked for editng by Joe Schmoe on 02/20/2004 at 10:00. Click UNLOCK to edit this record. THIS MAY DISCARD CHANGES MADE BY JOE SCHMOE." Clicking unlock replaces Joe's lock with Mary's. If Joe tries to save, he will see the message: "Your changes were not saved because your edit lock was removed by Mary Tidings on 02/20/2004 at 10:01" We make our users talk to each other to negotiate locks, and offer the force option for when computers crash or people open a record and go to lunch. >>>[EMAIL PROTECTED] 02/20 1:45 pm >>> Howdy, I am working on an intranet type solution, and am running into data integrity and record locking concerns.  The classic problem I want to solve is preventing one person from writing over the same record in an update that is being performed on the same record as another person.  1) User #1 loads record detail and begins to edit it. 2) User #2 loads same record detail and begins to edit it. 3) User #1 saves record to dB. 4) User #2 saves record to dB and overwrites #1's changes. I know everyone runs into this when dealing with shared record sets, so any thoughts on how others have solved this problem?  Here is my thought on the matter. 1) User #1 loads record detail and begins to edit it.    When record is loaded, an obj is instantiated with that records instance data and added into a statefull lock manager.  (This is locked to avoid race conditions) 2) User #2 loads same record detail and begins to edit it.    Lock manager checks to see if that obj. already exists in it, which it does, so it does not load a new one, but does increment the count of the number of people who     have that record open. 3) User #1 saves record to dB.    After save, the instance data of the obj in the lock manager is updated with the saved data, and the count of individuals with the record open is deincremented. 4) User #2 saves record to dB and overwrites #1's changes.    --Attempt to save, the instance data of the object to be saved is compared to the instance data of the object in the lock manager.  If the data is different, a message is     returned asking whether or not they would like to overwrite the new data.        --If yes, then the record is saved, and the obj open count in the lock manager is deincremented.          --If the open count is 0, then the object is deleted from the lock manager          --Else, the object in the lock manager is updated with the newly saved instance data. I think there are a couple problems with this:    1) Memory consumption.  I think my having to load in all these obj in the lock manager, you could potentially crash the server ---need some way to control the     amount of objects in the lock manager.    2) User leaves open record with out committing to the save so the open obj count in the lock manager would never be deincremented.    3) I know there are going to be problems relating to RACE conditions....so point them out!!!! Any thoughts, feel free to throw this idea up as you say 'PULL' and shoot it down =)  I am just starting to figure this out? Thanks again, Justin ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]