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?

Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to