Andreas Jung wrote at 2008-7-12 07:17 +0200:
... What do you mean by "higher level"? I think that the check within the ZPublisher is the highest and right place.
Code running after the commit() expects a new transaction and now will not get that.
You refer to code executed as part of a ZODB post-commit handler? If a transaction is doomed then such handlers should never be executed - right?
The problem is that a doomed transaction prevents "joining". This means that any operation that causes a join during error handling will fail. Examples are: accessing a session, accessing a relational database. The bug is in the ZODB ("transaction") code. A doomed transaction should not prevent joining. The only justification for the prevention is that "transaction" knows that any modification (potential cause of the join) will not be able to be committed (thus, "transaction" can indicate a problem earlier). *HOWEVER*, transactions can be joined for other purposes as modifications (example relational database access) and sometimes modifications should be possible even then they cannot be (and are not expected to be) committed (example error handling). Thus, please let us fix "transaction". -- Dieter