ZODB sticky conflicts (was: Re: [Zope-dev] Re: "hasattr" geddon)

[Dieter Maurer]

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