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