On Thu, 18 Apr 2002 17:35:17 + (UTC), Florent Guillaume
[EMAIL PROTECTED] wrote:
I'll investigate clearing the _v_ caches at the end of the transaction,
using the REQUEST._hold hack mentionned earlier.
Below is the class I use for this. Just call
attribute_cleaner(self,'_v_my_attribute')
Toby Dickenson [EMAIL PROTECTED] wrote:
Whenever a write comes in at the over-ten-second mark,
you write the _v_ attribute to the persistent attribute.
That would be bad. _v_ attributes are lost when the object is
deactivated and removed from the ZODB memory cache It would lose
the
Florent Guillaume wrote:
Or am I misunderstanding something ? My question really relates to any
use of _v_ as a cache that can survive on publisher transaction, really.
Should _v_ never be used like that ?
There's a case to be made for attributes that not persisted (like _v_
attributes)
On Thu, 18 Apr 2002 16:23:15 + (UTC), Florent Guillaume
[EMAIL PROTECTED] wrote:
This reminds me of a question I had: given that (from what I understand)
_v_ attributes only live in the object cache of a given Zope,
True, and more accurate that I think you expected
The issue is that
Ive never looked at LDAPUserFolder so this may be irrelevant, but is
it possible for LDAPUserFolder to validate that the cached _v_
information is still fresh? If that validation is quicker than
fetching a new copy then this is still an overall win.
yes it does have a very rough way of
Toby Dickenson [EMAIL PROTECTED] wrote:
This reminds me of a question I had: given that (from what I understand)
_v_ attributes only live in the object cache of a given Zope,
True, and more accurate that I think you expected
The issue is that one Zope has more than one ZODB object
