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 "ConflictError"s. 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