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
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:
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.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org