[ZODB-Dev] RE: [Zope-Annce] ZODB 3.2.4 release candidate 1released
Dieter Maurer
dieter at handshake.de
Fri Sep 10 13:22:51 EDT 2004
Chris McDonough wrote at 2004-9-9 22:19 -0400:
> ...
>But I *think* that it's only in the case that the exception which is
>raised is a ConflictError or a commit failure does ZODB have any
>responsibility whatsoever, and that's only because both are very fatal
>and there's no way to prevent either from being caught inappropriately
>by overeager exception handlers.
I see this completely different:
"ConflictError" does no more harm with respect to inconsistencies
than any other exception.
There are two major differences:
* "ConflictError" happens non-deterministically
* "ConflictError" are no real errors but behave somehow
like a warning or communication mechanism -- because
"ZPublisher" would abort the current transaction
and automatically retry.
Catching "ConflictError" means to turn a harmless warning
into non-deterministic (potential) inconsistencies or
non-deterministic errors (should the except clause
raise a different exception).
That's worse due to the non-determinism that makes
it very difficult to analyse why you have got inconsistent
persistent state.
> The machinery to make sure that
>nothing "bad" happens to persistent state at commit time due to
>inappropriately catching a ZODB-related exception is basically a hack,
>isn't it?
It would not call it a hack. It is a solution for
a small subproblem of a very general problem (Python's
abortive exception handling can leave inconsitencies behind) -- the
subproblem, the ZODB knows about (its own exceptions).
--
Dieter
More information about the ZODB-Dev
mailing list