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

[Mark Porter]

One possible problem with the dt_updateed solution is if two people save at the same time. Both will get the same value for dt_updated, so both will think it's safe to save,but one will overwrite the other in an unpredictable way. I had this bite me in the butt on a system with 4-5 users working with the same set of records and not talking to each other :) Thanks, Mark >>>[EMAIL PROTECTED] 02/20 2:38 pm >>> This is a pretty classic design issue in any "record editing" system.  The real question is whether or not it causes any harm to have the record overwritten.  Think of it this way . . . would two overlapping edits be any different than two edits that happen an hour apart?  Would User B change the data he is entering based on User A's changes?  In a lot of situations, it doesn't matter. If it does really matter in your system, then I think a lock-manager is a bit much for what you're trying to accomplish.  You could just as easily add a "dt_updated" timestamp to the record and check that.  All you have to do is retrieve the dt_updated with the rest of the data being edited and store it in a hidden field on your edit form.  Then when you commit the edit, if the timestamp differs from the one currently on the record, you can alert the user.  You get the same effect with no lock manager overhead. Roland Collins -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Balog Sent: Friday, February 20, 2004 3:46 PM To: '[EMAIL PROTECTED]' Subject: [CFCDev] [Kind of OT]: Record Locking and Avoiding Race Conditions? 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] ---------------------------------------------------------- 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]