(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 _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
