[Zope-dev] _p_deactivate() and _v_ variables?

[Casey Duncan]

Seb Bacon wrote:

> Chris Withers wrote:
>
>> Casey Duncan wrote:
>>
>>> I would argue that a better plan would be to only use _v_ vars for 
>>> completely disposable data only. The application should expect that 
>>> this values will be gone at any random time, not just at transaction 
>>> boundaries.
>>
>>
>> Agreed. Are there any situations, apart from the already discussed 
>> CMF skindata, where this currently isn't the case?
>
>
> I'm a bit puzzled - of what use is a variable which may disappear "at 
> any random time"?

It's not exactly random. It would happen when the object was deactivated 
(removed from cache). If the object is marked as changed (ala 
_p_changed=1) then its __getstate__ will be called before it is 
deactivated. If it hasn't changed though then it doesn't really get a 
chance to do anything about it.

Deactivation only happens AFAIK at transaction or subtransaction 
boundaries. This gives at least some predictability, since 
subtransactions are rarely used. Perhaps this is why database adapters 
have been historically incompatible with subtransactions?

It seems to me that DAs are a bit broken with regard to where they store 
their database connection objects. They should register an object with 
the transaction that holds the connection so that it can be properly 
committed or aborted regardless of what happens with _v_ variables in 
the interim.

-Casey