[ZODB-Dev] Shared/DC/ZRDB/TM.py:_register

[Dieter Maurer]

Vincent Pelletier wrote at 2008-5-14 02:49 +0200:
>Le Tuesday 13 May 2008 20:02:42 Dieter Maurer, vous avez écrit :
>> Someone convinced us that error handling should (of course)
>> see the state the error happened and not a new clean state -- in
>> order to be able to report about the errorneous state....
>
>Then, in my opinion, it should not be executed "inside" what failed, but in a 
>clean environment with a "pointer" (in non-technical meaning) to the failed 
>transaction.

Quite difficult and complex.

>> Another reason was also: should your error template need to run
>> in a fresh transaction, then just abort the old one.
>
>How ? IIRC it's a bad coding practice to interact with transaction mechanism 
>from what's considered as "inside" a transaction (ZPublisher being the 
>borderline).

That's what you have now. The border line is the end of request
processing (which includes error handling).


Think a bit about your wish:

  As soon as one transaction ends, a new one starts.

  What should happen with your artificial error handling transaction?
  Should it be aborted? or committed?. What should happen when the
  commit fails -- another error handling, in another error handling
  transaction?


The current behaviour is good in most cases.
If you dislike it in some special cases, abort the transaction
(you will get a new one, aborted automatically at the end
of error handling, unless you do the commit).

> ....
>Maybe 2 cases should be handled differently:
> - exception happened when processing transaction: do not abort immediately
> - exception happened in transaction handling (hopefully only in "commit"):
>   abort to offer error handling a "usable" environment

The better alternative would be to not prevent "join"s to
a doomed transaction.



-- 
Dieter