What about versioning? In our system, a version of every save is stored. So for us, in the scenario described below, Joe and Mary would each have a version stored that can be reverted to and made live if necessary. The system also simply stores versions (as work in progress) if the user chooses, or if the users permission level does not allow them to save a version live to the site.
I just thought that our system could be adapted to use a "lock" as described below. So if a particular chuck of content is opened for editing by a user Joe, and Mary comes along and opens it, the system would only save a version of Mary's edit and display a message to her that Joe is currently working on that same record. Of course, there is nothing to prevent Mary from opening the record just after Joe makes his save, edit it, and discard his changes in this fashion. The "lock" concept misses that scenario. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Hugo Ahlenius Sent: Tuesday, February 24, 2004 6:57 PM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] [Kind of OT]: Record Locking and Avoiding Race Condi tions? For such a scenario, I think it would be much better to have the lock at the "checkout" time. I'd hate to write up something, and then be told that I can't submit it... (even if I talk to someone about it, we would have the problem of merging our changes) ------------------------------------------------------------- Hugo Ahlenius E-Mail: [EMAIL PROTECTED] Project Officer Phone: +46 8 230460 UNEP GRID-Arendal Fax: +46 8 230441 Stockholm Office Mobile: +46 733 467111 WWW: http://www.grida.no ------------------------------------------------------------- | -----Original Message----- | From: Roland Collins [mailto:[EMAIL PROTECTED] | Sent: Tuesday, February 24, 2004 17:53 | To: [EMAIL PROTECTED] | Subject: RE: [CFCDev] [Kind of OT]: Record Locking and | Avoiding Race Condi tions? | | 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] | | ########################################### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ ---------------------------------------------------------- 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]
