[Zope-dev] Re: [ZCM] [ZC] 869/ 5 Comment "Broken transaction handling in case of exceptions"

[Toby Dickenson]

Lets take this back to the list.... Ive trimmed the cc list to people I think 
might be interested.

http://collector.zope.org/Zope/869

> I am not in line with your principle "the error report is
> part of [the output of] the first transaction". 

The error report tells you what went wrong. You can only generate an accurate 
report if you see the objects in the error state.  Zope is saying to your 
application: "your transaction is doomed. tell me why."

As you said:
> Drawback: you may see newer data in the error report than
> has been seen by the erroneous transaction.
I think thats a *major* drawback. The risk of zodb badness is a major drawback 
too..... Small risks add up over time.

> But, even with Zope, when the error report should do
> something persistently, it must do it in a new transaction
> as the old state is inconsistent and can not be committed.

I agree that it is unacceptable to commit changes made during the error report 
without starting a clean new transaction. I agree my proposal is inadequate 
if we need to allow this.

Currently Zope doesnt allow the error report to do something persistently, and 
the use case for this is not obvious to me. Can you explain the use case? I 
am hoping that there may be a better solution that avoids the problems I 
raised.

-- 
Toby Dickenson
http://www.geminidataloggers.com/people/tdickenson