[ZODB-Dev] [Enhancement Proposal] Garanteed lifetime for volatile
variables
Jim Fulton
jim at zope.com
Fri Oct 6 15:08:40 EDT 2006
Dieter Maurer wrote:
> Jim Fulton wrote at 2006-10-6 12:10 -0400:
>> ...
>> I'm a little uneasy about baking this policy so deeply into
>> the infrastructure. I wonder if the use case can be handled
>> another way.
>>
>> A persistent object can override _p_deactivate. For example:
>>
>> def _p_deactivate(self):
>> pass
>>
>> prevents an object from being turned into a ghost unless it is
>> invalidated.
>
> I think that
> this will not work -- unless more drastical changes are done to
> "persistent":
>
> When we invalidate an object, it must get deactivated.
>
> Now, currently invalidating a cache entry calls
> the object's "_p_invalidate" which calls
> "Per_set_changed(obj, NULL)" which uses "_p_deactivate"
> for the deactivation.
>
> With a definition like the above, the object will never
> again be deactivated -- not even when it is invalidated.
That is clearly a bug that is easily fixed.
>
>> 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.
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
More information about the ZODB-Dev
mailing list