Re: [ZODB-Dev] Storage API change: Checking for reading out-of-date data
Le lundi 30 août 2010 21:36:50, Jim Fulton a écrit : I've mistakenly tended to view this situation as an edge case. I confirm. I encountered similar problems when a given persistent object defines a transformation to be applied to another object (or more simply, when the presence/content of an object is used as a condition in a modification applied to another object). This is a fairly serious problem. It's serious enough that I'm, going to add some APIs in ZODB 3.10 to deal with it. One of these is: Looks nice. I'm quite interested in the API exposed by ZODB itself, especially for higher level use-casess. -- 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
Re: [ZODB-Dev] Storage API change: Checking for reading out-of-date data
On Mon, Aug 30, 2010 at 5:36 PM, Jim Fulton j...@zope.com wrote: ... This is a fairly serious problem. It's serious enough that I'm, going to add some APIs in ZODB 3.10 to deal with it. One of these is: class ReadVerifyingStorage(IStorage): def checkCurrentSerialInTransaction(oid, serial): Oops. That should have been: def checkCurrentSerialInTransaction(oid, serial, transaction): 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
Re: [ZODB-Dev] Storage API change: Checking for reading out-of-date data
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
Re: [ZODB-Dev] Storage API change: Checking for reading out-of-date data
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. Shane ___ 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
