Which, unfortunately, then leaves us with the problem of how to stop Zope using up an undeterminable amount of memory...
No, we just exclude objects with _v_ attribute from mid-transaction deactivation. There arent many objects in that category, but they do need protection.
Indeed, I guess they're unlikely to be the ones that cause Zope's memory usage to baloon...
But, your proposal means we would improve the situation for transactions that read from an undeterminable number of persistent objects.
Yep.
It does not help for transactions that touch an undeterminable number of non-persistent objects,
Under what circumstances is this likely to happen?
or transactions that change an undeterminable number of persistent objects. Is the gain big enough to justify the effort?
Well, hmmm, that's tricky. I guess that's the point where the fact that Zope so neatly hides the fact that it's interacting with a concurrent transactional database becomes a PITA.
I've written code in the past that just does a get_transaction().commit() half way through a request. I don't remember any problems, but how hot exactly is the fire I'm playing with?
cheers,
Chris
_______________________________________________
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 )
