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? alex
