[Zope-dev] zope2 webdav memory usage...

[Dieter Maurer]

Jim Fulton wrote at 2008-1-13 10:40 -0500:
>On Jan 13, 2008, at 7:49 AM, Dieter Maurer wrote:
>> Jim Fulton wrote at 2008-1-11 18:20 -0500:
>>> ...
>>> BTW, in situations in which you don't know which objects to
>>> deactivate, an alternative is to call cacheGC on the connection
>>> frequently.  This is fairly inexpensive and incremental.
>>
>> But, it can kill volatile variables as well -- which may
>> lead to trouble, until we have implemented something like
>> "Garanteed lifetime for volatile variables".
>>
>> Current potential trouble includes:
>>
>>  *  inconsistent transactions in relational databases
>>     (as "_v_" variables are used to hold the database connection)
>
>This is an interesting case.
>
>>
>>  *  broken Archetypes copy/move code
>>     (as "_v_" variables are used to communicate with
>>     'manage_afterAdd/beforeDelete further down the tree)
>
>Perhaps volatile variables are a bad idea.  They enable many subtle  
>errors.  OTOH, I fear that without them, people would resort to other  
>tricks that might be even worse.
>
>What sort of lifetime would you consider appropriate for volatile  
>variables? You example above suggests that they should stick around  
>until a transaction boundary (not including savepoints).

You know, there is a proposal from me about "Garanteed lifetime
for volatile variables" in the ZODB wiki for months -- and
we (in our private copy) use the corresponding implementation
for years (and this implementation was also committed to the
Zope bugtracker for years).

>I wonder if  
>there are other examples that might want something else.

I think that 2 lifetimes are sufficient:

  * can disappear at any time

  * lives at least until the (full) transaction boundary

>Or perhaps people should take the name "volatile" more seriously.

Then the legitimate use cases for attributes that are not
arbitrarily volatile (detailed in my proposal)
will need a different solution -- *AND* at least the Zope code
for database adapters must use this new solution.



-- 
Dieter