|
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
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]
|
