It's actually that the number of __del__-resurrecting objects *plus* the number of non-ghostifiable objects in cache is larger than the cache target size, right?
[Mario Lorenz]
Yes, but when you push the minimize button, the cache target size is 0.
That would do it <wink>.
Nonwithstanding our code (it was mostly debugging/tracing functionality anyway, so it was easy to fix),
I'm glad to hear that!
it is just that with Zope 2.5, it seemed to work (at least I never got a bug report back then) so it took us a while to track this down.
I expect that in your Zope 2.5 installation, the cache was implemented in a very different way. The current implementation is universally regarded as a major improvement. Maybe Toby remembers which release(s) of ZODB the current cache implementation first appeared in; it's not brand new, but is relatively recent.
Especially since we had just moved to RHEL3, so we were expecting more like a threading issue...
Be patient <wink>.
Given that this property is not that widely published (in the various tutorials etc.),
I believe the idea that a persistent object with a __del__ method could provoke an infinite loop in cPickleCache was news to all of us, and yours was the first report.
I wonder if it might be a good idea to improve that loop check code, and walk through the ring not more than once, using a counter, and not the comparison vs. the ring start, which, as we have seen, may be a target that moves too quickly.
We need to open Collector issues for ZODB bugs and patches, because they have a history of getting lost sometimes when confined to the mailing list. I opened an issue for this one here: http://zope.org/Collectors/Zope/1208