Re: [ZODB-Dev] Getting an up to date instance of a persistent object
On Jun 2, 2006, at 5:05 AM, Pascal Peregrina wrote: Below is a partial illustration of what I was saying earlier: in a given connection, just after a conn.sync(), if I access the _p_serial attribute of a persistent object and the object state is outdated, then the up to date state won't be loaded. But if I then access the _p_mtime attribute, the up to date state is loaded. The _p_mtime attribute is really the unusual one among the _p_* attributes in that accessing it will unghostify the instance (and this seems reasonable). I guess that _p_serial attribute should be understood to mean the serial number of the last loaded state. ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
RE: [ZODB-Dev] Getting an up to date instance of a persistent object
Now it all makes sense :) I was right in my initial assumptions then (but probably unclear when exposing it). Thanks a lot. Pascal -Message d'origine- De : David Binger [mailto:[EMAIL PROTECTED] Envoyé : vendredi 2 juin 2006 15:51 À : Pascal Peregrina Cc : Dieter Maurer; Federico Schwindt; Alejo Sanchez; zodb-dev@zope.org Objet : Re: [ZODB-Dev] Getting an up to date instance of a persistent object On Jun 2, 2006, at 5:05 AM, Pascal Peregrina wrote: Below is a partial illustration of what I was saying earlier: in a given connection, just after a conn.sync(), if I access the _p_serial attribute of a persistent object and the object state is outdated, then the up to date state won't be loaded. But if I then access the _p_mtime attribute, the up to date state is loaded. The _p_mtime attribute is really the unusual one among the _p_* attributes in that accessing it will unghostify the instance (and this seems reasonable). I guess that _p_serial attribute should be understood to mean the serial number of the last loaded state. ** 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. www.mimesweeper.com ** ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Getting an up to date instance of a persistent object
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. -- Dieter ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
