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

[Toby Dickenson]

On Friday 04 April 2003 8:55 pm, Dieter Maurer wrote:
> Toby Dickenson wrote at 2003-4-4 15:54 +0100:
>  > ....
>  > Access to the doomed state at the end of the transaction is what zope 2
>  > gives us today.
>
> This is not the case.
>
>   Zope 2 as it is now performs error handling in a separate
>   transaction.

Yes. I was aware of this of course, but hadnt fully appreciated the 
implications for this debate. Thanks for the reminder. 

>  > It is important that the objects passed from one transaction to the next
>  > are non-persistent, otherwise bad zodb-level things can happen. Does
>  > Zope 3 guard against this?
>
> I do not see this.
>
>   Caches routinely pass persistent objects from one transaction to the
>   next.

Are there any examples in stock Zope 2? I would consider this a bug.

>   And think of a non-Zope ZODB application.
>   This application is likely to have references to persistent
>   objects in its variables and on its stack and will
>   probably use it across transactions.
>   At transaction boundaries the state of some of these
>   objects is invalidated and reloaded transparently in the following
>   transaction, if necessary.

I have some applications that work this way too. It is ok for applications 
that dont have a need need to be highly robust, but I dont think this 
approach belongs in the zope core.

>   Sure, when the object was deleted, a POSKeyError will result.
>   This is what should happen.

There are scenarios where this POSKeyError is permanent, not transient. If a 
dangling reference has been committed into the storage then there may be no 
way to recover without manual repair of the storage.

Im not sure that it cant do other damage too. it seems to me that zodb wasnt 
designed to operate in this manner.

> I have two use cases:
>
>   *  sending email about (some) severe errors.
>
>      We can use a non-transactional mail sender for this
>      purpose although it would be nice to send all mail
>      through a single (transactional) mailhost.
>
>   *  gathering statistics about/logging errors in a relational database

IMO none of the proposed solutions are ideal for this. If the 
log-to-relational bit of the error reporting fails, you probably still want 
the error log email to be sent anyway and you probably dont want to fall back 
to zopes default (ugly) error page. Also, you dont necessarily need these 
actions to be run before sending the error page back to the server. 

It seems to me that these use cases call for a transaction that runs soon 
*after* the error event. It should be *seperate* to the method which 
generates the error report seen by the user.

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