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
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
