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