ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Boisvert" <boisv...@intalio.com>
Subject Re: Server error handling
Date Sat, 05 Apr 2008 15:26:11 GMT
On Sat, Apr 5, 2008 at 7:16 AM, Tammo van Lessen <tvanlessen@gmail.com>
wrote:

> we had the same discussion a while ago when I added some code to
> swallow all exceptions that occur in event handlers. But (I think it
> was Alex) finally convinced me that event handlers should be capable
> throw exceptions which result in aborting the transaction. There are
> several use cases for such an behavior like strict
> requirements/obligations regarding audit data. In a real-world
> environment storing audit data in a reliable fashion is an absolute
> MUST. So in case of a data bases error, network fragmentation,
> harddisk crash etc, the event listener must be able to interrupt the
> actual execution because the execution can not be completed in the
> intended way (i.e. having all events in an audit trail can not be
> guaranteed anymore).


It was probably me and I still stand by it ;)


> Another use case would be "process repair". In
> case you have received a certain sequence of events you may figure out
> that the process instance does not behave in the intended way. In such
> a case you may want to either "repair" variable values or may want to
> fail the process instance.


I had not considered this use-case yet;  I think it's an interesting one
although it would probably need non-trivial work to implement in a way
that's similar to the current activity recovery mechanism.

I believe these are convincing points, therefore I suggest to either
> put the responsibility to catch runtime exceptions to the event
> handler developer or to introduce a dedicated exception for the
> explicitly reporting/wrapping an error and swallowing all runtime
> exceptions in Ode.


I also assumed it was the responsibility of the event handler to behave...
although Matthieu seems to think the engine should generalize the
rollback/ignore behavior.

But in general I agree that Ode should deal with such an exception in
> a meaningful manner, i.e. it should create a BPEL fault which then
> either bubbles back to the client or even could be caught by a BPEL
> faultHandler.


So we have 3 cases now,

   1. Rollback transaction if there's an internal exception related to
   the event handler and report a failure to outstanding message exchanges
   instead of timeout
   2. Ignore internal exceptions related to event handler
   3. Use a special exception to signify the process should go into some
   form of recovery/repair mode.

The second part of #1 is the outstanding bug that Thilina filed.   (And
there might be a bigger problem if the engine quits as a result; we need to
investigate)

#2 would possibly be a small enhancement;  Matthieu proposed a change to the
even handler interface.  I was thinking it could be a deployment
configuration option (at the event handler level).   Or we can leave it as
it is and assume the event handler swallows all exceptions if desired.

#3 is a bigger enhancement.  I like the idea but we need a volunteer or
somebody who has a significant itch.

Is this a fair assessment?

alex

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message