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
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
