[ZODB-Dev] Shared/DC/ZRDB/TM.py:_register

[Vincent Pelletier]

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:

https://bugs.launchpad.net/zope2/+bug/142446
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 
(https://bugs.launchpad.net/zope2/+bug/142446/comments/3).

>   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 
handled.

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.

-- 
Vincent Pelletier