On Mon, May 24, 2010 at 10:57 AM, Vincent Pelletier <vinc...@nexedi.com> wrote:
> Le dimanche 23 mai 2010 16:11:44, Jim Fulton a écrit :
> Getting a bit more out of initial topic: I am currently searching for papers
> describing how conflict resolution is supposed to happen, and more exactly if
> it is safe to "chain-resolve" for a single transaction.
IMO, there's nothing particularly "safe" about conflict
resolution. Conflict resolution weakens transaction isolation in ways
that can (but generally don't :) produce incorrect transactions. In
the future, in addition to doing conflict resolution on the client,
I'd like to make it more configurable so that, among other things, it
can be disabled.
> Example, using a similar representation of action as in Atul Adya thesis:
> w1(x1) w2(x2) c2 c1
> -> conflict for x1, "based" on x0 and to "rebase" onto x2, so transaction 1
> starts resolving. In the meanwhile:
> w3(c3) c3 w1(x1') c1
> -> conflict for transaction 1 again. This step can be repeated as many times
> as desired, then eventually:
> w1(x1") c1
> -> success
I don't follow the above.
> I could not find a doc spelling out this case yet.
Let me see if I understand the case:
If we do conflict resolution before the commit lock is held,
then there if a chance that the object under conflict gets updated
again while we're doing conflict resolution, so we may have to to
conflict resolution again. Is that the case you're talking about?
This case can't occur in the current ZODB implementation, so there's
nothing written about it.
> >From what you said on lock not being held during the first phase, I infer
> it is already standard for this to happen.
That's not what I said. I said it gets the lock at the end of the
first phase. The lock is held while conflict resolution is
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org