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 _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )