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

[Tim Peters]

[Tim Peters]
>> ...
>> 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 Maurer]
> Shane provided one.
>
>
> Here is another trivial one.
>
>      obj.persistentAttr1 = 1
>      ...
>      # raise an exception here
>      ...
>      obj.persistenAttr2 = obj.persitentAttr1
>
> This snipped allows to assume an invariant: after any transaction
> "persistentAttr2 == persistentAttr1".

I'm sorry, but I'm not following this, probably because there are no commits
in the example.  Where are you assuming they occur?

> Now let someone catch the exception (withou reraising this or another
> one) -- invariant violated.

Since there's no commit in the example, the database never changes,
exception or not.  If there's an assumed commit following the last line, I
still don't see the problem.  If the "raise an exception part" was, e.g.,

    try:
        get_transaction().commit()
    except:
        pass

same thing.  Then the invariant can't be expected to hold even if the commit
succeeds (persistentAttr1 was changed at commit() time, but not yet
persistentAttr2).  If the commit fails, fine, the change to persistentAttr1
is reverted, and the assumed commit (if there is one ...) at the end
maintains the invariant.

If it's really the case that the "raise an exception" part is *not* caught,
and is not a POSError of some kind, and some higher-level routine goes on to
do a commit, then yes, a change is made to persistentAttr1 but not to
persistentAttr2.  But then that's not due to suppressing an exception, it's
due to not suppressing one, so that the code never got to its "change
persistentAttr2" part.

> The example (of course) means application related consistency and not
> internal consistency.

Well, I don't "get" this example, but there are lots of ways to screw up
intended invariants among multiple objects, even in the absence of
exceptions.  For example, say I is an IIBucket, and an intended invariant is
that at most one of I[1] and I[2] is non-zero.  T1 and T2 see I[1] == I[2]
== 0 at the start, T1 sets I[1] to 1, T2 sets I[2] to 2, and both commit.
No exceptions, no suppressions, and both transactions satisfy the intended
invariant on their own, but the final bucket state violates it.