On Sun, Jul 13, 2008 at 09:05:16AM +0200, Dieter Maurer wrote:
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.
Do you have an example of this bug? It should be fixed. It is already tested in doom.txt like this: A doomed transaction should act the same as an active transaction, so we should be able to join it: >>> txn = transaction.begin() >>> txn.doom() >>> dm2 = DataManager() >>> txn.join(dm2) But perhaps there is another way to make it fail?
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).
Yep, you should still be able to join doomed transactions. According to the first line of doom.txt, the intention of doom is: A doomed transaction behaves exactly the same way as an active transaction but raises an error on any attempt to commit it, thus forcing an abort.
Thus, please let us fix "transaction".
-- Dieter
-- Brian Sutherland