On Mon, Aug 30, 2010 at 6:39 PM, Shane Hathaway <sh...@hathawaymix.org> wrote: > On 08/30/2010 03:36 PM, Jim Fulton wrote: >> >> The tricky thing about this is the last paragraph. If the method >> doesn't raise an error, then there can't be updates to the object >> until after the transaction commits. For most current >> implementations, this implies that the storage lock is help when this >> is called. For ZEO, some special care will be necessary because the >> storage lock isn't acquired until the very end of the first phase of >> 2-phase commit. >> >> I'm particularly concerned about the impact on RelStorage. > > Thanks for calling attention to this. Like ZEO, RelStorage doesn't acquire > the commit lock until the end of the first phase of 2-phase commit, for > performance reasons. Therefore, if I understand correctly, ZEO and > RelStorage will have to maintain a list of OID/serials that the transaction > is depending on, then check that list after the commit lock is acquired (but > still in the first phase). If anything has changed, we should raise a > ReadConflictError. Does that sound right?
Yes > BTW, perhaps the method name and signature could be as simple as > "require(oid, serial)". It simply declares to the storage that the > transaction requires a specific version of an object. While I'm open to better names, I prefer a longer more descriptive name. Jim -- Jim Fulton _______________________________________________ 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