Tim Peters wrote at 2004-7-10 17:55 -0400:
... Which is why the current ZODB releases intend to prevent committing a transaction if a conflict error occurred during the transaction. It shouldn't matter to this ZODB machinery if the application suppressed the original conflict error(s), ZODB remembers that it raised ReadConflictError regardless (via the Connection._conflicts set-implemented-as-a-dict).
Hmm. The lack of design documentation is frustrating. Staring at the code, it could be that ZODB only prevents a transaction commit if the transaction tries to *commit* at least one object that suffered a conflict error, I don't know ... if you have a specific case in mind, please open a Collector report about it.
This is indeed the case: The code you mentioned prevents the modification (i.e. "commit") of an object that caused a "ReadConflictError" when it has been accessed -- whether or not the exception has been caught or not. Shane seems to want a stricter behaviour: something like: def commit(...): ... if self._conflicts: raise SpecialConflictError(...) i.e. prevent the commit, when the transaction saw any conflict whether or not it tries to modify such an object. However, I think his wish is not necessary. Even when a "ReadConflictError" was swallowed, the object has not been read and its state is still undefined. Whenever the application tries to read an attribute, the object is refetched and the "ReadConflict" reissued. When the conflict successfully trickles down to the "commit", then in fact, the transaction was independent from the state of the respective object... The only thing, the application can do is do write the object. However, "writing" implies fetching the object -- with the consequence of another "ReadConflict" (if I am right, then the code in "commit" is redundant, as the application is unable to write an object that could not be fetched due to a "ReadConflict"). The problem that remains: The application swallowed an exception and, as a consequence, did not recognize that it was unable to *write* an object. It performs its other writes and commits. In this case, the originally written object remains unchanged and inconsistent with respect to other objects. Shanes wish would recognize this situation. Obviously, I have to retract my previous thought :-) -- Dieter