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

[Vincent Pelletier]

(Re-send because I forgot to CC the list)

Le Monday 19 May 2008 21:13:49, vous avez écrit :
> Think a bit about your wish:
>
>   As soon as one transaction ends, a new one starts.
>
>   What should happen with your artificial error handling transaction?
>   Should it be aborted? or committed?.

I think it should be aborted. Partly because it's what happens currently, and 
because I don't think there is any need to permanently modify data in the 
error hook. If one wants to do so, I guess he will just write an error path 
in his code.

>   What should happen when the 
>   commit fails -- another error handling, in another error handling
>   transaction?

I see this as an argument against commiting the error-hook transaction.

> The current behaviour is good in most cases.
> If you dislike it in some special cases, abort the transaction
> (you will get a new one, aborted automatically at the end
> of error handling, unless you do the commit).

The point is that I don't see why it would be bad in those "most cases" to 
systematicaly abort.
I did the modification I suggested in the bug report before submiting it, and 
the error page still renders the error traceback properly. Could you be more 
specific about what's missing from error hook if original transaction is 
aborted ?

> The better alternative would be to not prevent "join"s to
> a doomed transaction.

Right. Only commits should be prevented (they currently are when exception 
happened during TPC).
I'm not sure about the case where exception was raised before TPC: should 
commits be prevented in this case too ? Maybe it's the coder's responsibility 
not to call commit in the error hook.

-- 
Vincent Pelletier