Le Thursday 22 May 2008 10:40:46, vous avez écrit :
> Maybe, you search the "zope-dev" archive to find the thread that convinced
> us to change the former behaviour (the one you want now again)
> into the current one?
Adding links for possible future reference:
First discusses a problem with handling erorr outside of any transaction,
suggesting a fix similar to mine, and then later it was agreed that failed
transaction should be aborted after error handling
> The same can apply to "__traceback_info__" and "__traceback_supplement__"
> information derived from persistent objects.
> This information will then reflect the persistent state as it
> has been when the transaction started and not as it was when the
> exception occurred.
I see. Thanks.
And the problem with providing a "pointer" to such information is the same as
having 2 transactions simultaneously started for the same thread, I guess.
> The ZODB has a notion of "doomed transaction".
> A transaction gets doomed when something happens that can
> can lead to persistent inconsistencies should the
> transaction be committed.
> A failing "commit" and an unsuccessful reset to a savepoint
> are example "doom" reasons. I am not sure whether a "ReadConflictError",
> too, dooms the transaction.
BTW, the usual error hook treats conflict error exceptions differently from
others, and I guess it was done so because those can happen in TPC. In my
case, the problem was triggered by MultipleUndoErrors, which is not specialy
I have the feeling that current exception class inheritance scheme is not so
good, and that it would be needed to create more abstract exceptions classes
to inherit from. For example, an exception class which would instruct
publisher to retry transaction and another to instruct it to give up (...and
of course abort transaction) as fast as possible.
I have no idea about the needed amount of work.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org