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

[kapil thangavelu]

On 12/10/03 10:29 AM, "Jeremy Hylton" <jeremy at zope.com> wrote:

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

afaik, there are two major use cases. one, application caches, which for the
most part can be recomputed, though not always. two, external resource
integration, things get nasty here when dealing with transaction aware
external resources in the current setup when volatile connections to ext
resources can disappear mid transaction. this problem affects all the
existing zope database adapters.  note in the case of database adapters, the
volatiles want to exist as long as possible to avoid startup costs with the
connection. so I think there are two categories of volatile lifecycle needed
by applications, per transaction, and as long as possible (but again ended
at transaction boundary).

I think this can be simplified into one category of live as long as possible
and those that do need per transaction usage of this can integrate with the
transaction machinery to do clean up, though this might be more overhead
than users of transactional volatiles would want.

dieter wrote
>There are two options:
>
>  *  abandon "_v_" variables for such use cases
>
 >    We then need a new device for these use cases

the only alternative I've found acceptable is to convert uses of _v_ to a
system of module level global variables for use as thread specific storages
with application linking (I normally cheat and use _p_oid) to items in the
storages. for legacy code _v_* get converted to computed attributes with
accessors that do lookup and creation, it works.. but ick.

+1 on longer lifecycle volatile variants.

-kapil