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

[Casey Duncan]

Toby Dickenson wrote:

>On Wednesday 15 October 2003 14:53, Casey Duncan wrote:
>
>  
>
>>>>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).
>>    
>>
>
>The proposal earlier in the thread was aiming towards allowing objects to get 
>deactivated at any time if the cache was overfull, not just at transaction 
>boundaries. This is desirable from a cache management point of view.
>
>Apart from the most trivial cases, it would allow _v_ attributes to disappear 
>at random. Its a similar problem to the one that makes it hard to write an 
>optimiser for python code, and I am unconvinced that this is sane.
>  
>
I agree. If objects disappeared from cache randomly, I think the system 
as a whole would not be stable or predictable.

I also think it would tend to make a loaded server even more loaded by 
thrashing the cache unnecessarily. As it is, the hard cache 
implementation, although beneficial from a memory management perspective 
cause loaded servers to do alot more work because they are constantly 
pruning the cache and then reloading objects again immediately thereafter.

It might be worth considering a more gradual cache mgmt policy which has 
a target size, a maximum size and a prune rate. Currently, we have only 
a maximum size. Then again, since Python never really returns memory to 
the OS, I'm not sure it matters much in the end.

-Casey