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:aathan@memeplex.com>) 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