RE: does EOEditingContext.refreshObject work?
RE: does EOEditingContext.refreshObject work?
- Subject: RE: does EOEditingContext.refreshObject work?
- From: Chuck Hill <email@hidden>
- Date: Sat, 20 Dec 2003 19:41:09 -0800
At 10:15 PM 20/12/2003 -0500, Adam Ramadan wrote:
>
>> What is it that you are trying to achieve?
>
>I'm trying to lock the object while one user is modifying it. It's possible
>that the lock expires or is removed by an admin, so before I save my changes
>I ensure that the user still holds the lock - so I was trying to refresh the
>data to see if the user with the lock had changed. If the refresh is buggy I
>can redesign this scheme, but if there was a workaround that would let me
>somehow tell WebObjects that the field was "dirty" and needed to be saved,
>that would save me some time and effort. (I have read the relevent
>WebObjects documentation concerning update strategies and what WebObjects
>provides, but I couldn't see a way to fully implement my requirements within
>their framework).
>
>I didn't realize that this method was new to 5.2.2 - maybe there is a way to
>achieve the same result as the refreshObject method does with more mature
>methods? I'll experiment a bit.
>
I'll first observe that pessimistic locking and web applications is often a
bad combination. OK, now I feel better. :-)
It seems to be that even if your scheme worked it would still be subject to
a race condition in which the lock was removed by the admin (or timed out)
after you refresh but before your changes hit the database. The only way
to avoid a race condition is to use either full pessimistic locking (which
I don't recommend) or rely on the default optimistic locking of WO. Using
optimistic locking, you indicate in the EOModel which attributes you want
to lock on. When saving changes if a value in the committed snapshot does
not match what is currently in the database an exception is thrown from
saveChanges(). At that point the user needs to be shown the data again and
asked to confirm it.
It will get trickier than this. What I wrote above only applies to
conflicts across instances / processes. It is quite possible that another
user in the same instance has already modified the same object and saved it
by the time the user in question saves. In this case, the shared committed
snapshot will have been updated and no conflict will be detected.
EOEditingContext has delegate methods that can be implemented to control
what happens in this situation. I'm sure there was an article or chapter
in a book on this, but I can't lay my hands on it right now.
Chuck
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.