[Zope-dev] transaction.doom() and ZPublisher

[Brian Sutherland]

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