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
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
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
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 Fulton mailto:[EMAIL PROTECTED] Python
CTO (540) 361-1714
Zope Corporation http://www.zope.com http://www.zope.org
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org