Comment 3 for bug 98275

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