Hi, (moving this from user to dev)
Alex Boisvert wrote:
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?
Regarding #2 and #3: The special exception I mentioned was supposed to be a solution for #2. My idea was to add a checked exception that indicates that Ode shall rollback the transaction and should throw a BPEL fault while unchecked exceptions are simply swallowed (logged but ignored). I tend to prefer this over adding a call back method as this implies more changes to the interface (need for an abstract class) and is IMHO not that intuitive to use.
I don't think a repair (#3) mode can be part of Ode itself but should be rather implemented in such an event handler (be it process specific or generic which most probably implies to put people into the loop).
Cheers, Tammo
