[ZDP] BackTalk to Document Zope Developer's Guide (2.4 edition)/ZODB Persistent Components

webmaster@zope.org webmaster@zope.org
Sat, 05 Oct 2002 10:44:45 -0400

A comment to the paragraph below was recently added via http://www.zope.org/Documentation/Books/ZDG/current/Persistence.stx#2-27


    Volatile attributes are useful for data that is good to cache for
    a while but can often be thrown away and easily recreated.  File
    connections, cached calculations, rendered templates, all of these
    kinds of things are useful applications of volatile
    attributes. You must exercise care when using volatile attributes.
    Since you have little control over when your objects are moved in
    and out of memory, you never know when your volatile attributes
    may disappear.

      % poster - May 13, 2002 9:43 am:
       I assume that you can count on a volatile attribute remaining within the life of a method call that creates
       it. What about within a transaction? In general, while I understand there will be a point at which you can no
       longer rely on the existence of a volatile attribute, when *can* you rely on it?

      % reiman - Aug. 16, 2002 12:13 pm:
       I also just learned that _v_ attributes are thread-specific. This too should be mentioned (and explained)

      % beyond - Oct. 5, 2002 10:44 am:
       Within one transaction you can rely on _v_ attributes (afaik). 
       Each thread gets its own transaction. So another thread -> another _v_ attribute 
       -> you can't rely on it in different transactions. Tansactions are kept in a pool
       and objects are cached so sometimes when accessing an object with a new 
       request (which gets the old transaction out of the pool) the object is still cached
       and it won't get loaded out of ZODB and then __setstate__ won't get called and 
       finally the _v_ attribute remains. But this is of course not relyable. I'm just 
       telling you this special case because recently I got some strange errors which were
       caused by this behavior.