Vincent Pelletier wrote at 2008-5-13 10:36 +0200: > ... >To reproduce the problem: > - create a class inheriting from TM, and define a method calling register. > Add logs to abort and commit method to track transaction end. > - create a default error page which triggers a call to the method created > above. (this is equivalent to accessing some database from the error page, > for example) > Call it twice. > Most realistic case is using an instance surviving the transaction (a > global, or a persistant object) > - tigger an error in TPC (a raise in vote is the most realistic case) and get > the error page to render. The most obvious breakage I could see is when > trying to undo an non-undoable transaction (modify a script twice, undo the > oldest without undoing the newest) > >Here is what happens: > - first transaction (the "undo" in my example) raises in TPC, transaction is > marked as failed > - error message gets rendered in the same transaction (that's a ZPublisher > bug, but I think the problem "root" is hiding the failure)
Formerly, the transaction was aborted before error handling. Someone convinced us that error handling should (of course) see the state the error happened and not a new clean state -- in order to be able to report about the errorneous state.... Therefore, it was changed. And I think, it was correct to change it. Another reason was also: should your error template need to run in a fresh transaction, then just abort the old one. If the transaction were aborted before error handling, then an error template with different requirements does not have a chance.... -- Dieter _______________________________________________ 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
