Christian Theune wrote:
On Thu, 2004-04-01 at 00:25, Ian Beatty wrote:

I thought "Okay, no problem. I'll just make the lock variable volatile,
since I don't really care whether it persists when Zope shuts down." So I
renamed the lock to begin with '_v_'. That solves my "UnpickleableError"
problem nicely. Unfortunately, it introduces a different problem: the code
that calls acquire() on the lock now throws "AttributeError: 'NoneType'
object has no attribute 'acquire'". I'm sure I initialize that variable to a
threading.Lock() in the object's __init__ method. So now I'm worried that
Zope is doing all kinds of pickling-unpickling activity behind the scenes,
and anything I have that's volatile can disappear without warning.

I'm not sure about this right now, but iirc _v_ attributes are not
stored until "zope shutdown" but until the object is reloaded from the
ZODB (for whatever reason it went out of the cache). This basically
means no availability longer than until the end of one request can be

'_v_' variablews are not stored *at all* in the ZODB; they are only useful for caching an expensive computed value. In fact, the ZODB does not even guarantee that volatile won't go away during a single request, although objects are not normally ghosted until the end of a transaction. Any use of volatiles needs careful thought.

An example:;

class Bar:

      def __init__( self ):
          """ do something really expensive here.

class Foo( Persistent ):

_v_bar = None

      def _getBar( self ):
          result = self._v_bar
          if result is None:
              result = self._v_bar = Bar()
          return result

# Always use self._getBar() instead of self._v_bar.....

I don't think volatility is a good match for locks, which are tasked with ensuring consistency.

Tres Seaver                                [EMAIL PROTECTED]
Zope Corporation      "Zope Dealers"

Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - )

Reply via email to