Zope's current transaction behaviour is essentially:
## request starts
transaction.begin()
try:
object= REQUEST.traverse(...)
mapply(object,...)
transaction.commit()
except:
transaction.abort()
handle_error()
## request ends
This is flawed as error handling is done outside of a transaction.
Potential changes during the error handling spill over
uncontrolled into another request and are there
either committed or aborted as part of this request.
Andrew Athan (<mailto:<email address hidden>>) has had lots
of serious inconsistencies in Zope's session data.
After extensive analysis, he found out that reading
the session data during error handling led to these
error conditions (reading session data causes writes to
the administrative data).
I suggest, we let Zope perform error handling in its own
transaction after the original transaction had been aborted.
When error handling succeeds, its transaction is committed,
otherwise aborted.
The new behaviour would look something like this:
## request starts
transaction.begin()
try:
object= REQUEST.traverse(...)
mapply(object,...)
transaction.commit()
except:
transaction.abort()
transaction.begin()
transaction.note('%s (application error handling)'
% '/'.join(object.getPhysicalPath)
)
try:
handle_error()
transaction.commit()
except:
default_handle_error() # Zope's default error handling
# it should not have side effects
# and is executed inside the
# error handling transaction
transaction.abort()
## request ends
--- See discussion in "zope-dev".
I'm currently implementing similar behaviour for zope 3.
However, introducing this behaviour in zope2 could break applications that themselves clear cached or computed data on transaction boundaries. This data would not be available for the error page.
I think ZPatterns applications sometimes rely on the current behaviour, so this change would break certain zpatterns applications.