[Zope-dev] Cache growing during single REQUEST

[Toby Dickenson]

On Friday 05 September 2003 14:21, Chris Withers wrote:

> Hmmm, maybe not... could we make a note of the pickles size when the data
> is loaded and update that size when it's comitted? Is this the same as the
> in-memory size?

Yes, I hope its close enough for most purposes. It would be nice to have a way 
for the object to override that in the cases where it is badly wrong.

> >>then boot an object out of the cache in order to make room for the new
> >> one.
> >
> > That would have a bad effect on ReadConflictErrors.
>
> Don't follow, can you explain?

You get a ReadConflictError when loading an object if it has been modified 
since the start of the transaction. This exception therefore becomes 
increasingly likely as time progresses since the start of the transaction.

Today you can minimise the probability of a read conflict by touching the 
objects you need (at least the ones likely to change) near the start of the 
transaction. This works because, once loaded, the objects stay in memory 
until the end of the transaction.


Another problem I didnt mention is that _v_ attributes are supposed to last at 
least until the end of the transaction.

> > I havent seen a mention of ulimit or autolance earlier in this thread....
> > They are mostly adequate protection against the work problems.
>
> Do they kill the thread or the whole Zope?

whole zope

of course there isnt a great overhead in using twice as many zopes, each with 
half as many publisher threads. (assuming you already have zeo, of course)

> I'm also keen for users to nto
> get MemoryErrors, but to just have their request take much longer ( cache
> thrashing and the like...)

use squid, and it will retry the request.

-- 
Toby Dickenson