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.


Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - )

Reply via email to