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?

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.

For more information about ZODB, see the ZODB Wiki:

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

Reply via email to