[ZCM] [ZC] 786/ 4 Comment "Session gets munged"

[Collector: Zope Bugs, Features, and Patches ...]

Issue #786 Update (Comment) "Session gets munged"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/786

==============================================================
= Comment - Entry #4 by mcdonc on Feb 2, 2003 7:06 pm

I don't see Publish.py using "freeme=1" anywhere.  Can you provide a line number?
________________________________________
= Comment - Entry #3 by mcdonc on Feb 2, 2003 7:05 pm

Andrew Athan, via email:

> It seems clear that at the very least, the abort(freeme=1) should be
> changed to an abort(freeme=0); is this, at least, not in debate?

> As far as commit() in an error handler, I might agree from a purist
> standpoint that state is likely to be inconsistent, but it is > also true
> that (IMHO) this state should be inspectable and reportable.  If you
> abort() the transaction before the error handler, there is no way to
> report on that state -- the inconsistency itself can help track down
> problems.

> As far as whether an error handler should commit anything, I can
> certainly imagine packing heuristics into an error handler such that it
> can find, fix and react to certain classes of errors.  Python provides
> enough context to do so.

> Whether this would be a common, or event recommended, design pattern ...
> Different question.

> A.
________________________________________
= Comment - Entry #2 by stevea on Feb 2, 2003 5:05 am

An error handler should never be allowed to commit the transaction that an exception was raised in. An exception punches through the various frames in the stack, and the error handler has no way of knowing what state may have been left inconsistent.
________________________________________
= Request - Entry #1 by Anonymous User on Jan 31, 2003 4:52 pm

Publish.py does an abort(freeme=1) upon catching an exception.  It then calls the registered error handlers (e.g., resolves to standard_error_message).  if the SESSION is referenced (even read only) within this error handler, there is a high probability that the session data structures (index[] and data[]) will get messed up.

This seems to be a direct result of traversing persistent objects outside the context of any Transaction.

I feel that Publish.py should only abort(freeme=1) AFTER any error handler is called.  The error handler is would then be free to commit() if it feels it has fixed the problem, or do nothing to let Zope abort().
==============================================================