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

Dieter Maurer dieter at handshake.de
Fri Oct 6 15:35:29 EDT 2006


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?

     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.

     In principle, all objects in the cache can be relevant...

  *  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.

     This means we need an additional callback activated after
     the cache garbage collection to get rid of the instance
     level "_p_sticky" again.



-- 
Dieter


More information about the ZODB-Dev mailing list