Vincent Pelletier wrote at 2008-5-14 02:49 +0200: >Le Tuesday 13 May 2008 20:02:42 Dieter Maurer, vous avez écrit : >> 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.... > >Then, in my opinion, it should not be executed "inside" what failed, but in a >clean environment with a "pointer" (in non-technical meaning) to the failed >transaction.
Quite difficult and complex. >> Another reason was also: should your error template need to run >> in a fresh transaction, then just abort the old one. > >How ? IIRC it's a bad coding practice to interact with transaction mechanism >from what's considered as "inside" a transaction (ZPublisher being the >borderline). That's what you have now. The border line is the end of request processing (which includes error handling). 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?. What should happen when the commit fails -- another error handling, in another error handling 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). > .... >Maybe 2 cases should be handled differently: > - exception happened when processing transaction: do not abort immediately > - exception happened in transaction handling (hopefully only in "commit"): > abort to offer error handling a "usable" environment The better alternative would be to not prevent "join"s to a doomed transaction. -- 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
