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

[Jim Fulton]

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.

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

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

All objects are 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?

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

I don't really follow this. I'm not sure I need to.

I have a feeling that there's some deeper issue lurking here.
I'll have to think about this some more.

Some observations:

- This isn't unique to _v_ attributes.  An object could
   have other non-persistent data that is precious.

- I wonder if an argument could be made than we shouldn't
   implicitly deactivate an object that has been accessed in a
   a transaction while the transaction is still running.

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