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