[Zope-dev] Re: [ZCM] [ZC] 869/ 5 Comment Broken transaction handling in case of exceptions
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Re: [ZCM] [ZC] 869/ 5 Comment Broken transaction handling in case of exceptions
The view has access to the original request that ended in the error. The view is looked-up and rendered in a new transaction. A new transaction means that *arbitrary* changes may have occurred to the application state in between: 1. the transaction that raise the error, and 2. the transaction that reports it In principal it is posssible to delete the database state and import a whole new application between these two points. The object containing the originally published method might no longer exist. I guess that might not matter if your error page just says sorry an internal error has occurred - if you want your users to be shielded from the details of any problem. I have some applications at the other extreme, where the users are all capable of debugging any problem and I want the error page to be a core dump of application state. Can you give an example of the kind of situation where you'd need access to objects in a doomed transaction in their doomed state, in order to make an error report? Access to the doomed state at the end of the transaction is what zope 2 gives us today. Access to the objects restored to their state as they were at the beginning of the failing transaction would be ok too (maybe even better) but zodb cant do that today. Either of these two are necessary for easily providing an error report that displays application state explaining why the error occurred. Under the Zope 3 model I think I would need to take a non-persistent copy of the application state in an exception handler towards the end of the first transaction. The second, error-reporting transaction would dump the copy, rather than dump what it sees to be the current world state. 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? -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
[Zope-dev] Re: [ZCM] [ZC] 869/ 5 Comment Broken transaction handling in case of exceptions
Toby Dickenson wrote at 2003-4-4 10:24 +0100: ... 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. 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 Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Re: [ZCM] [ZC] 869/ 5 Comment Broken transaction handling in case of exceptions
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. However, the error handling transaction is not committed/aborted explicitely. It is aborted implicitly later in a different request (as you pointed out correctly: in the transaction.begin() that [re]uses the implicitly created transaction.). But this abort may affect connections that are meanwhile used by different requests causing non-deterministic invalidation and aborts. That needs to be fixed, either as your suggest by delaying the abort for the original transaction until error handling finished (making error handling part of the original transaction) or by performing error handling in its own explicit transaction (as I suggest). ... 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. 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. Sure, when the object was deleted, a POSKeyError will result. This is what should happen. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
