Comment 4 for bug 98275

Minor note. The bug is that changes to an object are registered
while __getstate__ is being called. I think the object should remain
in the changed state until later. presumably the object is getting
into the uptodate state too soon. This analysis is without looking
at the code. :)

On Oct 10, 2007, at 11:00 AM, Christian Theune wrote:

> Ok, I investigated this and found out what is causing it.
>
> I used Tim's test case.
>
> 1. The object (Mine) is instanciated and added to the root object.
> 2. The serialization will discover the new persistent subobject in
> the root. When the object is stored, it's __getstate__ method will
> be called.
> 3. The __getstate__ modifies the object's state which will cause it
> to be registered with the connection.
> 4. The client cache will be invalidated for the new object and
> updated with the new data.
> 5. The object will be stored a second time, (due to the explict
> registration with the connection) and the client cache will be
> invalidated again.
> 6. As the current transaction invalidated the cache already in this
> transaction we hit the point that cur_tid == tid.
>
> I can see multiple solutions here:
>
> - forbid to change an object when its __getstate__ method is called
> - make the connection/serialization smarter to avoid having objects
> registered multiple times
> - make the client cache allow invalidating current data
>
> --
> ZEO versus creative __getstate__
> https://bugs.launchpad.net/bugs/98275
> You received this bug notification because you are a member of Zodb-
> developers, which is the registrant for ZODB.

--
Jim Fulton
Zope Corporation