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 guaranteed.
'_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. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com