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 PROTECTED]>) 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
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 )
