(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
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
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
> 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.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org