Dieter Maurer wrote:
Jim Fulton wrote at 2006-10-6 16:02 -0400:
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):

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.

You miss my "Class level sticky declaration" use case...

Registering when I set the "_v_" variable would probably not be enough
at least not when the registration is valid only for one transaction --
what I expect (but am not sure of):

   The "_p_sticky" would need to be deactivated at any transaction
   boundary as long as the object is in the cache -- independent
   of whether or not I have set any "_v_" variable in the transaction.

     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

And this is difficult when the registration is only active for a single
transaction: the object may remain in the cache without me touching
it in the following transactions. Nevertheless, it should be possible
to garbage collect it at transaction boundaries.

If, on the other hand, the registration is active until explicitely canceled,
I explicitely need to cancel it when the object is flushed from
the cache. I would have to add respective code in "_p_deactivate"
(which I have already overridden) and in "_p_invalidate" (which
I would need to override as well).

     In principle, all objects in the cache can be relevant...
All objects are sticky?

The "Class level sticky declaration" use case means that sticky
objects can come into existence without any explicit action.

Thus, while not all objects are sticky, any object in the cache could
be 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?

As explained in the proposal:

  We have 3 use cases for volatile attributes:

I didn't ask why you use volatile attributes.

I asked why _p_sticky needs to be stored on each instance,
since it is set at the class level.


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

No: only "_v_" attributes are lost at deactivation

No, normally all state is lost at deactivation, including _v_
attributes.  Of course, most other state can be reloaded
from the database.


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -

Reply via email to