Re: Optimistic Locking issues (was Re: Exception: lock operation fetched row with diff...than snapshot)
Re: Optimistic Locking issues (was Re: Exception: lock operation fetched row with diff...than snapshot)
- Subject: Re: Optimistic Locking issues (was Re: Exception: lock operation fetched row with diff...than snapshot)
- From: Jonathan Rochkind <email@hidden>
- Date: Mon, 19 Jan 2004 13:43:48 -0600
Yes, these are good points. Concurrency makes an already complex
situation even more complex, and I'm not sure of the answers either.
I'm mainly just glad that I don't really have to deal with the issue.
EOF's facilities for handling optimisic locking, which at first seem
very sophisticated (and may even be very sophisicated; I have not
compared it to any other environments)... well, in the real world, if
you are dealing with data where you really need to handle this stuff
securely and insure that everybody writes what they meant to write,
nobody overwrites someone elses changes without meaning to, and all
your data is 'sane'----it's a huge huge problem, not solved by EOF's
apparent sophisticated optimistic locking mechanisms. At least
that's how it looks to me.
--Jonathan
At 11:22 AM -0800 1/19/04, Chuck Hill wrote:
And I'm still wondering when the delegate gets notified if requests
are getting dispatched concurrently. Two saves could be initiated at
the same time. EOF will serialize them so that one blocks while the
other proceeds. But where will it block? Will the delegate get
called if the ec is locked? If it does get called, will your code
still have a chance to raise and abort the save? Will that hose the
ec? (I'm a little suspicious that the ec cannot handle exceptions
thrown where it does not expect them).
Chuck
Jonathan Rochkind wrote:
But the EC does get notified that this record got changed, correct? So, can
we address the problem by
1) having application/page handle that notification
2) reject the user's edits and tell him that someone else modified the data
already.
3) refresh the display.
Is that notification to the EC detailed enough for this strategy?
Yes, you can do that. There is an EOEditingContext delegate method
which is probaby the easiest place to do it, where you definitely
have all the information you need. Writing the code is still kind
of a pain. Personally, what I think needs to be done, is someone
needs to write an implementation of this EC delegate method (or
perhaps an EC subclass in general would be required) to essentially
raise an optimistic locking exception (on saveChanges), just as if
the first editor was in another instance. To regularize things so
two within-EOF-stack editors produce the exact same optimistic
locking behavior, based on attributes used for locking in the
model, as a change from an editor in another EOF stack (or a non-WO
app, or whatever) produces. This would still be tricky code to
write, but you'd only have to write it once, and after that you
wouldn't have to worry about this confusing issue anymore.
Maybe I'm missing something or confused about something myself;
this is a confusing issue.
--Jonathan
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
It is a funny thing about life; if you refuse to accept
anything but the best, you very often get it."
-- W. Somerset Maugham
<shamelessPlug>
Practical WebObjects
http://www.amazon.com/exec/obidos/tg/detail/-/1590592964
</shamelessPlug>
_______________________________________________
WebObjects-dev mailing list
email@hidden
http://www.omnigroup.com/mailman/listinfo/webobjects-dev
_______________________________________________
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.