RE: conflict resolution for PersistentList

[Chris McDonough]
> AFAIK, it's a bug in whatever version of ZODB that you're using that you
> are allowed to commit inconsistent state back to the database after
> there has been a read conflict error, even one which is mistakenly
> caught by your own exception handler.  It just should raise a separate
> conflict error at commit time, and even if *that* is mistakenly caught,
> you shouldn't see inconsistent state in the database from a different
> connection afterwards (the commit would have failed).

I think the fix forcing suppressed conflicts to prevent commit got lost (so
far as ZODB's NEWS.txt is concerned, not in the code) in the crush of news
about fixing corruption due to the then-lack of atomic invalidations (which
could cause corruption even if no conflicts were suppressed).  The easiest
way to check is probably to look in ZODB/tests/testZODB.py, and see whether
this test function exists:

    def checkReadConflictIgnored(self):
        # Test that an application that catches a read conflict and
        # continues can not commit the transaction later.
        ...



_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@xxxxxxxx
http://mail.zope.org/mailman/listinfo/zodb-dev