Re: Concurrency question
Re: Concurrency question
- Subject: Re: Concurrency question
- From: Mike Schrag <email@hidden>
- Date: Thu, 2 Aug 2007 07:49:01 -0400
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:
Attachment:
Preview of “RaceCondition.graffle”.pdf
Description: Adobe PDF document
Here's the "no optimistic lock exception" example:
Attachment:
Preview of “NoOptimisticLock.graffle”.pdf
Description: Adobe PDF document
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden