Le dimanche 23 mai 2010 16:11:44, Jim Fulton a écrit :
> I'm not sure what you mean by object level locks.  I've been planning to
> add something similar to object-level locks during the commit process, so
> multiple transactions can be doing commit-related activity at once.

That's the feature I intended to express.

> Independent of that, It should be possible to check for conflicts and
> deal with them on the client during the first phase of 2-phase commit.

Yes, this is how it's done in NEO (and IIRC in ZEO), by making "store" return 
a None until answers are received from server.

> Note that ZEO doesn't get the storage lock until the end of the first
> phase.

Ah, I missed this.

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.
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 could not find a doc spelling out this case yet.
>From what you said on lock not being held during the first phase, I infer that 
it is already standard for this to happen.

> As with NEO, zc.zodbdgc was motivated by multiple databases where a single
> database doesn't have enough information to perform garbage collection.

Thanks for pointing this package out, I didn't know it.

Vincent Pelletier
For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to