[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