Toby Dickenson wrote at 2003-4-6 20:50 +0100:
...
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.
The ZODB caches (implemented by yourself) do.
.... 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.
I am starting to agree that your proposal is the better one: * The standard case will be that error handling does not change the ZODB state. For this standard case, it is not relevant whether it is executed in the old transaction or a new one. * Your use case requires that error handling is done in the original transaction. When the framework aborts it, there is no way to implement it. * My use cases can explicitely abort the old transaction and start a new one -- in case the framework delays abortion. * Having several transactions in a single request makes handling of "ConflictError"s in later transactions mode difficult. Dieter