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

Dieter Maurer dieter at handshake.de
Fri Oct 6 14:54:52 EDT 2006


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.
  

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



-- 
Dieter


More information about the ZODB-Dev mailing list