[ZODB-Dev] [Enhancement Proposal] Garanteed lifetime for volatile variables

[Jim Fulton]

Dieter Maurer wrote:
> Jim Fulton wrote at 2006-10-6 16:02 -0400:
>> Dieter Maurer wrote:
>>> Jim Fulton wrote at 2006-10-6 15:08 -0400:
>>>> ...
>>>>>> You could implement your sticky attribute at the application level:
>>>>>>
>>>>>>
>>>>>>     def _p_deactivate(self):
>>>>>>         if getattr(self, '_p_sticky', False):
>>>>>>            return
>>>>>>         Persistent._p_deactivate(self)
>>>>>>
>>>>>> You could provide any policy you want, without making the policy part
>>>>>> of ZODB.
>>>>> But, such an object would never again be deactivated (unless
>>>>> "_p_sticky" is reset). In my proposal, such objects may be
>>>>> invalidated at transaction boundaries.
>>>>>
>>>>> This may not be a big problem, as there are probably not too many
>>>>> objects that have "_p_sticky" defined permanently
>>>>> ("Shared.DC.ZRDB.Connection" and
>>>>> "Products.CMFCore.Skinnable.ObjectManager" would be examples).
>>>> Good point.  I left off that you could register a callback on transaction
>>>> commit to clear the sticky flag.
>>> Not a nice perspective -- for too reasons:
>>>
>>>   *  When would I register the callback?
>> When you set the volatile data that needed to be sticky.
> 
> You miss my "Class level sticky declaration" use case...
> 
> 
> Registering when I set the "_v_" variable would probably not be enough
> at least not when the registration is valid only for one transaction --
> what I expect (but am not sure of):
> 
>    The "_p_sticky" would need to be deactivated at any transaction
>    boundary as long as the object is in the cache -- independent
>    of whether or not I have set any "_v_" variable in the transaction.
> 
>> ...
>>>      Sure, the callback should not need to look at all objects in
>>>      the cache to find the sticky ones.
>>>
>>>      This means, the callback would need to be registered for
>>>      each object potentially relevant at transaction boundary time.
>> Yes, any object that needed to be sticky would need to have a callback
>> registered.
> 
> And this is difficult when the registration is only active for a single
> transaction: the object may remain in the cache without me touching
> it in the following transactions. Nevertheless, it should be possible
> to garbage collect it at transaction boundaries.
> 
> If, on the other hand, the registration is active until explicitely canceled,
> I explicitely need to cancel it when the object is flushed from
> the cache. I would have to add respective code in "_p_deactivate"
> (which I have already overridden) and in "_p_invalidate" (which
> I would need to override as well).
> 
>>>      In principle, all objects in the cache can be relevant...
>> All objects are sticky?
> 
> The "Class level sticky declaration" use case means that sticky
> objects can come into existence without any explicit action.
> 
> Thus, while not all objects are sticky, any object in the cache could
> be sticky.
> 
>>>   *  The examples above have their "_p_sticky" defined at
>>>      class level -- as they make vital use of volatile attributes
>>>      and need a garanteed lifetime for them until transaction boundary.
>> Hm, so stickyness is a property of the class?  Why store _p_sticky on
>> the instance then?
> 
> As explained in the proposal:
> 
>   We have 3 use cases for volatile attributes:

I didn't ask why you use volatile attributes.

I asked why _p_sticky needs to be stored on each instance,
since it is set at the class level.

...

>> - This isn't unique to _v_ attributes.  An object could
>>   have other non-persistent data that is precious.
> 
> No: only "_v_" attributes are lost at deactivation

No, normally all state is lost at deactivation, including _v_
attributes.  Of course, most other state can be reloaded
from the database.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org