Pascal Peregrina wrote:

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).

(note that I use ZEO)

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.

Let's say C2 modified the same object. At C2 commit time, tpc_finish calls self._db.invalidate of all objects that C2 modified. Through a series of callbacks (involving ZEO also if used), this notifies all other connections through their invalidate() method that this object is invalidated. C1.invalidate() records that fact, and at C1 commit time there will be a conflict error if O1 is modified while also flagged invalidated by another connection.


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.

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)

Is that right? What's the rule?

Thanks for your help.


This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -

Florent Guillaume, Nuxeo (Paris, France)   Director of R&D
+33 1 40 33 71 59   [EMAIL PROTECTED]
For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -

Reply via email to