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)
> ...
>ConflictError: database conflict error (oid 0x7905e6, class
>BTrees._IOBTree.IOBucket, serial this txn started with
>0x036ddc2b3e989fdd 2007-05-25 09:15:14.670982, serial currently
>committed 0x036ddc2dd48f4e33 2007-05-25 09:17:49.818700)

These log entries indicate a bug in ZODB's invalidation processing.

  The first entry tells us that the object was read at 9:14:16
  and the modification conflicts with a write from 9:16:07.

  The second entry tells us that the object was read at 9:15:14
  *BUT* at the time this transaction has started,
  the ZODB should already have known the modification from 9:16:07
  and the object read at 9:15:14 should have been invalidated.
  The new transaction should not have seen any state older than 9:16:07
  (as it begins after this time).

In older ZODB versions, there has been a bug in
"ZODB.Connection.Connection._setDB". It has forgotten to flush invalidations
(which may lead to observations as the above).

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
        if self._reset_counter != global_reset_counter:
            # New code is in place.  Start a new cache.
        # 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).

Maybe, the bug you see now affects only mounted connections?

For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -

Reply via email to