On Wednesday 03 September 2003 12:15, Chris Withers wrote:
If the object load would cause the cache to go above it's maximum number,
*Number* isnt the the right parameter to control here..... We need to limit the total amount of RAM. Objects are of variable size, and the largest ZODB objects are very much bigger than the average.
This is true, but isn't this much harder to do as we run into the same issue that people have trying to produce folderish objects for Zope that limit the size of their contained objects?
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?
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?
Cache purging should only happen on transaction boundaries for storages where ReadConflictErrors are possible.
Can you put some brackets in that statement, I don't follow it..
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? I'm also keen for users to nto get MemoryErrors, but to just have their request take much longer ( cache thrashing and the like...)
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce