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:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org
_______________________________________________
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

Reply via email to