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

[Brian Sutherland]

On Sat, Jul 12, 2008 at 07:17:31AM +0200, Andreas Jung wrote:
>
>
> --On 10. Juli 2008 17:09:36 +0200 Brian Sutherland 
> <brian at vanguardistas.net> wrote:
>
>> On Thu, Jul 10, 2008 at 12:12:06AM -0400, Paul Winkler wrote:
>>> Hi,
>
>
>>
>> I havn't investigated properly, but it may be necessary to do the
>> isDoomed() check at a higher level where you can abort.
>
> What do you mean by "higher level"? I think that the check  within the 
> ZPublisher is the highest and right place.

Ok, as I said, I havn't investigated properly.

>> 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?

If I see a function named "commit" I expect that calling it will cause a
commit, or raise an error. I don't expect that nothing will happen and I
will have the same transaction after as before.

So this part of the patch:

     def commit(self):                                                                                                                                
-        transaction.commit()                                                                                                                         
+        if not transaction.get().isDoomed():                                                                                                         
+            transaction.commit()  

Changes the meaning of the commit() function from "Commit or error" to
"maybe commit, or maybe do nothing, or maybe error".

That raises lots of warning bells in my head. But, it's probably OK,
depending on what the code calling commit() expects.

>
>
> Andreas



-- 
Brian Sutherland