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
this could be used for a very crude check
of potential serializability conflicts along the following

  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.

For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -

Reply via email to