Hi!
Well, I think the best solution would go the way as Core Data
went. Basically, the lucky guys I know who do all the bells and
whistles with desktop apps say that Core Data editing contexts are
independent. IE, no auto-updating, no problems at all.
I don't know if going no auto-updating contexts would be a good
idea (I don't really know why this is done in WO anyway, it was some
advantages but also some disadvantages), but DEFINITELY the OL should
work based on the context snapshot, and not on the raw row snapshot.
Basically, whatever is done should keep this in mind: one should
only have to solve the concurrency problem once. We have to do it for
inter-instances concurrency, with OL. We shouldn't have to do it
again, with "synchronized" and so and so on intra-instance concurrency.
Yours
Miguel Arroz
On 2007/08/02, at 12:49, Mike Schrag wrote:
On Aug 2, 2007, at 1:12 AM, Chuck Hill wrote:
The problem comes in when the modifications are made and saved
after your editing context has been locked in the RR loop. I
tricked ;-) Mike into looking at this today with. Looks like
tigers lurk here. Maybe Mike will comment.
Chuck and I looked into this some yesterday ... It would appear
that there is, in our opinion, some bugs related to optimistic
locking within a single EOF stack. Essentially what it boils down
to is that it appears that the update database operation that is
created as a result of a call to .saveChanges() is backed by the
EODatabaseContext snapshot and NOT the "working" snapshot inside in
the EO in the editing context it came from. What this means is
that while changes are not merged until you .unlock() and .lock()
under normal circumstances, because the underlying snapshot that
EOF diffs your changes against on save is the DBC snapshot, it's
effectively inadvertently "merged" on commit. That is to say that
if another EC makes changes and saves, then you make different
changes and save, you will blow away their changes with no sign of
an optimistic locking exception because your snapshot IS their
snapshot now (meaning, it looks like just you are overwriting their
changes, versus the reality of the situation that you are actually
conflicting with their changes). After discussing this some, we
believe that if the update operation used a version of the EO's
backing snapshot instead that these weird behaviors would be fixed
and it would behave exactly like a normal conflicting update if you
were in two EOF stacks. The current behavior smells of bug, but
I'm curious if anyone a dissenting opinion on the topic. It's
certainly really complicated and nasty down in that code, so it's
possible there's some crazy justifiable reason for it.
Here are two diagrams of examples ... Left side is EC 1, right side
is EC 2, purple is the state of the EO in EC1 at various points,
yellow is the state of the same EO in EC2 at various points.
Here's the "blow-away-other-changes-in-the-EO" workflow:
<Preview of “RaceCondition.graffle”.pdf>
Here's the "no optimistic lock exception" example:
<Preview of “NoOptimisticLock.graffle”.pdf>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/arroz%
40guiamac.com
This email sent to [EMAIL PROTECTED]
Miguel Arroz
http://www.terminalapp.net
http://www.ipragma.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
