On Sat, Apr 5, 2008 at 8:26 AM, Alex Boisvert <[EMAIL PROTECTED]> wrote:
> On Sat, Apr 5, 2008 at 7:16 AM, Tammo van Lessen <[EMAIL PROTECTED]> > 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? > Sounds fair to me. For #2 I'm of the opinion that it should be part of the event handler interface as it's something you want the API implementer to be aware of. So I proposed (in the Jira issue created by Thilina) to add a method like failOnError() so the handler can signify the expected engine behavior. About #3 I have mixed feeling. This would mandate exposing the engine state (both the OModel and Jacob) to the outside world, effectively making the running state a public interface. We can't guarantee the stability of this interface, we want to able to change it at anytime. So even if self-repair sounds like a seducing idea, from an implementation standpoint it would probably be a headache to maintain. Matthieu > > alex >
