Hi Dieter,

thanks for this hint.

Dieter Maurer schrieb:
Perry wrote at 2007-5-25 13:16 +0200:
database conflict error (oid 0x7905e6, class BTrees._IOBTree.IOBucket,
serial this txn started with 0x036ddc2a44454dee 2007-05-25
09:14:16.000950, serial currently committed 0x036ddc2c21950377
2007-05-25 09:16:07.870801) (80 conflicts (10 unresolved) since startup
at Fri May 25 05:19:08 2007)

In our private Zope version, I have still a note like this:

        # DM 2005-08-22: always call '_flush_invalidations' as it does
        #  more than cache handling only
        self._flush_invalidations()
        if self._reset_counter != global_reset_counter:
            # New code is in place.  Start a new cache.
            self._resetCache()
        # DM 2005-08-22: always call '_flush_invalidations'
##        else:
##            self._flush_invalidations()

The note indicates that the bug was fixed at least at 2005-08-22
(though the handling was not completely right in case the cache
was reset).
In ZODB.Connection.Connection.open I see:

        if self._reset_counter != global_reset_counter:
            # New code is in place.  Start a new cache.
            self._resetCache()
        else:
            self._flush_invalidations()

So self._flush_invalidations() is only called in the else-condition.
In your patch it is always called. I try your version and report back.



--
Gruß Joachim

_______________________________________________
Zope-Dev maillist  -  Zope-Dev@zope.org
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 )

Reply via email to