[Zope-dev] Cache growing during single REQUEST

[Chris Withers]

Toby Dickenson wrote:
> On Friday 05 September 2003 14:21, Chris Withers wrote:
> 
[pickle size = memory usage]
> 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.

Good call, that sounds like an excellent plan...

> 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.

What's the thing Zope Corp are touting as the long term solution to this problem?

> 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.

Right, but if you need to touch them to avoid Read Conflicts, surely that means 
the other transaction which was likely to stomp on your objects gets the 
ReadConflict instead? Is that any better?

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

bugger :-(
What abotu subtransactions?

> 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)

Hmmm, not pretty though, is it?

cheers,

Chris