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  -

Reply via email to