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: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
