[ZODB-Dev] RE: [Zope-Annce] ZODB 3.2.4 release candidate 1released

[Tim Peters]

[Tim]
>> ...
>> I don't know of a scenario in current ZODB wherein catching something
>> can make a database inconsistent.  I understand there are persistent
>> rumors that it can happen, but requests for a specific case have gone
>> unanswered.

[Dieter]
> Shane provided one.

I think you must mean this:

    http://mail.zope.org/pipermail/zope-dev/2004-July/023414.html

I didn't understand that one either <0.4 wink>.  I got closer to
understanding the intent by the time it got to here:

    http://mail.zope.org/pipermail/zope-dev/2004-July/023426.html

but ran out of time for staring at these threads then.  That one's still
sitting in my inbox.  I'll note now that this exchange (from the last link)
was based on misunderstanding:

[Tim]
>> 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,  

[Dieter]
> 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.

The grunge I didn't understand at the time was that the machinery to raise
ReadConflictError *also* registers the conflicted oid with the transaction,
so that the transaction does feed the conflicted oid back to
Connection.commit() at Transaction.commit() time, and despite that the
object was never loaded (let alone modified).  It does this precisely (and
only) to guarantee that the transaction can never commit.  It's a trick (the
oid gets registered not because it's a modified object, just to force a
later exception), but an effective trick.

Of course it's still the case that a failing Transaction.commit()
effectively begins a brand new transaction -- and that's part of what's
driving ChrisM to distraction today too.  I can certainly understand how
transactions "beginning by magic" due to suppressing commit() exceptions can
lead to application inconsistency.