[ZODB-Dev] [ zodb-Bugs-637279 ] ConflictError mishandling

[noreply@sourceforge.net]

Bugs item #637279, was opened at 2002-11-12 13:20
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=115628&aid=637279&group_id=15628

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Shane Hathaway (hathawsh)
Assigned to: Nobody/Anonymous (nobody)
Summary: ConflictError mishandling

Initial Comment:
After a ConflictError, ZODB 3 lets the application
continue as if no conflict has happened. Jeremy and I
agreed that it should not be possible to commit a
transaction in which a ConflictError has at any time
propagated to the application.  ZODB 3 lets conflicting
data get committed.

A test program is attached.  It runs two threads.  The
data written to root['data'] is intended to generate a
conflict error (this is good). The data written to
root[container_name] is not intended to generate a
conflict error (this is also good).  When the program
attempts to write conflicting data, all data gets
reverted to the original state (this is okay).

The data written to root['container3'] is the problem.
 If the application catches a conflict error and
ignores it, it is able to write more data, and the new
data could be inconsistent with the rest of the data. 
Here is the output of the test program:

About to commit.  Root data: 'apple', container1 data:
'apple'
Committed.  Root data: 'apple', container1 data:
'apple', container3 data: 'apple'
About to commit.  Root data: 'orange', container2 data:
'orange'
Got a conflict.  Ignoring.
Committed.  Root data: 'apple', container2 data: None,
container3 data: 'orange'

Everything is fine until the last line.  The app should
not have been allowed to write "orange" to container3,
because that value is out of sync with the rest of the
data.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=115628&aid=637279&group_id=15628