Re: [ZODB-Dev] Serializability
On Aug 21, 2007, at 1:55 PM, Dieter Maurer wrote: Jim Fulton wrote at 2007-8-20 10:32 -0400: ... Application specific conflict resolution would become a really difficult task. I'm sure you realize that application specific conflict resolution violates serializability. No, I do not realize this. Assume a counter which is not read only incremented/decremented. Its application specific conflict resolution ensures that the schedule is serializable restricted to the counter value. Things are much more complex when the counter is read (and incremented). Usually, serializability is lost, then. I should have been more precise. When application-level conflict resolution is used, then the database is no-longer providing serializability. It is up to the application to do so (or to provide correctness in some other way. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Serializability
Jim Fulton wrote at 2007-8-20 10:32 -0400: ... Application specific conflict resolution would become a really difficult task. I'm sure you realize that application specific conflict resolution violates serializability. No, I do not realize this. Assume a counter which is not read only incremented/decremented. Its application specific conflict resolution ensures that the schedule is serializable restricted to the counter value. Things are much more complex when the counter is read (and incremented). Usually, serializability is lost, then. -- Dieter ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Serializability
On Aug 19, 2007, at 9:34 AM, Dieter Maurer wrote: Analysing the STICKY behaviour of 'Persistent', I recognized that 'Persistent' does not customize the '__getattr__' but in fact the '__getattribute__' method. Therefore, 'Persistent' is informed about any attribute access and not only attribute access on a ghosted instance. Thogether with the 'accessed' call in Jim's proposal http://wiki.zope.org/ZODB/DecouplePersistenceDatabaseAndCache;, this could be used for a very crude check of potential serializability conflicts along the following lines. The DataManager maintains a set of objects accessed during a transaction. At transaction start, this set is empty and all cached objects are in state 'Ghost' or 'Saved'. Whenever an object is accessed for the first time, the DataManager's 'accessed' or 'register' method is called. In both cases, the manager adds the object to its accessed set. At transaction end, the manager can check whether the state of any of its accessed objects has changed in the meantime. If not, no serializability conflict happened. Otherwise, a conflict would be possible (provided the transaction changed any objects). Yup. I'd like someday to provide this sort of check as an option. The test is very crude, as it does not track whether the tracked transaction's change really depends on one of the objects changed by different transactions. We must expect lots of ConflictErrors. Perhaps. I would expect more, but whether there are lots will depend on the application. Application specific conflict resolution would become a really difficult task. I'm sure you realize that application specific conflict resolution violates serializability. I have a hard time believing that someone would use this higher-level serializability mode together with conflict resolution. At least not in general. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
[ZODB-Dev] Serializability
Analysing the STICKY behaviour of 'Persistent', I recognized that 'Persistent' does not customize the '__getattr__' but in fact the '__getattribute__' method. Therefore, 'Persistent' is informed about any attribute access and not only attribute access on a ghosted instance. Thogether with the 'accessed' call in Jim's proposal http://wiki.zope.org/ZODB/DecouplePersistenceDatabaseAndCache;, this could be used for a very crude check of potential serializability conflicts along the following lines. The DataManager maintains a set of objects accessed during a transaction. At transaction start, this set is empty and all cached objects are in state 'Ghost' or 'Saved'. Whenever an object is accessed for the first time, the DataManager's 'accessed' or 'register' method is called. In both cases, the manager adds the object to its accessed set. At transaction end, the manager can check whether the state of any of its accessed objects has changed in the meantime. If not, no serializability conflict happened. Otherwise, a conflict would be possible (provided the transaction changed any objects). The test is very crude, as it does not track whether the tracked transaction's change really depends on one of the objects changed by different transactions. We must expect lots of ConflictErrors. Application specific conflict resolution would become a really difficult task. -- Dieter ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
