ZODB sticky conflicts (was: Re: [Zope-dev] Re: "hasattr" geddon)
Dieter Maurer
dieter at handshake.de
Mon Jul 12 13:34:43 EDT 2004
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
More information about the Zope-Dev
mailing list