Pascal Peregrina wrote at 2006-5-24 09:57 +0100:
>I have a question regarding what triggers the reloading of an object
>state from ZODB (in order to set the most up to date one).
There is only one reason: that it is not in the cache or a ghost.
At transaction boundaries (and only there!) objects modified
in other connections are deactivated (ghosted).
>Say you have C1, a Connection, and you have already retrieved object O1
>(so O1 is in C1 cache).
>Then, O1 is modified by something (that uses a different Connection).
>When you reuse C1 and access O1, I would like to know what makes sure
>the O1 state is up to date.
Nothing, if the modification happened since the last transaction
boundary (or call to the connections "_setDB").
>Apparently, accessing O1._p_serial before anything else returns the old
>serial (so the latest state has not been set). I also tried C1.sync()
>(through O1._p_jar) before accessing O1._p_serial but I got same result.
This is strange -- and should not happen (in ZODB 3.4 or above).
>And apparently, accessing O1._p_mitme before anything else does return
>the latest mtime and then accessing O1._p_serial does return the latest
>serial (so the latest state has been set)
That sounds unbelievable...
>Is that right?
Almost surely not.
>What's the rule?
>From ZODB 3.4 on, objects modified in a foreign connections
are deactivated (ghosted) at transaction boundaries.
Objects not in the cache or ghosted are reloaded on access.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org