[ZODB-Dev] [Problem] "_v_" variables too volatile

[Jeremy Hylton]

On Wed, 2003-12-10 at 13:12, Toby Dickenson wrote:
> On Wednesday 10 December 2003 16:17, Jeremy Hylton wrote:
> 
> > > There
> > > are cases where I set _v_ variables (and in fact it's most cases) where I
> > > could care less if the object is flushed on subtransactions. IOW I think
> > > using _p_dont_deactivate should be the exception and not the rule.

Actually, Casey wrote this, not me.  I don't think I've ever written
code that uses _v_ variables :-).

> I suspect you believe this is safe because you are assuming that the cache 
> collector will never be activated at some points in your code, and you are 
> assuming that the cache collector will only be triggered by a subtransaction.

It does assume that, true.  Or it assumes that programmers should be
prepared for _v_ attributes to go away, as you discuss below.  I don't
know how people use _v_ or how volatile they expect the attributes to
be.

> That assumption might be true in some limited cases today, but it is brittle. 
> Im sure something would break if code making this assumption was mixed with 
> some of my cache-hungry Zope Products.

Are there any examples I can look at?

> It will certainly not be true in future.... The extreme case is when we allow 
> the cache can trigger some deactivations itself, to prevent it ever growing 
> too large. I am assuming that what we design for volatile attributes today 
> will need to cope with this.
> 
> For example, the following code would be unsafe, because self might get 
> deactivated (removing all _v_ attributes) between the hasattr check and using 
> _v_bar.
> 
>     def foo(self):
>         if not hasattr(self,'_v_bar'):
>             self._v_bar = self._make_bar()
>         ....use some other persistent objects
>         ....and self._v_bar at the same time.
> 

This code would only be unsafe if the cache evicted objects
mid-transaction, right?  Otherwise, there should only be one thread
using the cache and no reason to expect evictions to occur.

I agree that _v_ variables don't seem very useful if they can disappear
immediately after you assign to them, but in the current implementation
they don't, right?

> > > Explicit is better than implicit.
> 
> Safe-by-default is better than explicit
> 
> I hope that all makes sense....

Safe by default is good, yes.

Jeremy