The Global Exception Handler in WLI.+ transactions

Feb 12, 2008 java english
Share on:

In every WLI process you may construct individual exception handling mechanisms for each perform- step that try to handle the exceptions or propagate them to a more generic construct that resides on the top of your process (see the image above). It is often referred as the Global Exception Handler. You Just add an Exception Path on the top of the process.

I have to admit that I really had a hard time to eventually get it sort of right in terms of making the global exception handler make something useful instead of creating an unreasonable amount of exceptions.

According to Weblogic Integration documentation specific steps (Async calls, Finish steps etc) provide by default specific behavior when it comes to transaction boundaries.For example an ASync Step inside the global Exception handler chain -would try to commit the underlying transaction. In this case if your handler is trying to handle a RollBackTransaction Exception - then WLI unleashes hell of exceptions - trying to commit a transaction that is marked for rollback!

I have to admit I am not the guru of WLI and at some point I found the behavior of Weblogic integration comparing to the documentation weird. I have to point out the following things, that actually helped me a bit!

  • On the process level - always pay attention on the following attribute

  • freeze on failure - Simple enough what do you want the process to do when failure occurs

  • On the Exception level - always consult documentation and your requirements

  • afterExecute= In other words, what you want to do after the exception is executed.Really really important

  • executeOnRollback - tricky option, set this to true if you want the handler to act just before the underlying transaction is going for a rollback!

I can not give specific tips on which values should be there it is really a matter of what your handler is supposed to do and how the aborted or frozen or resumed processes should continue their lives' inside the wli space.

My experience is limited though - in the cases where the Global exception handler was executed in a RollBackTransaction Exception - I found out that doing funcy and magic things - always proved to be - very risky! For some reason implicit transaction boundaries inside the exception path - were not working at all -(I don't know why) - my workaround is to delegate work on underlying EJB's with REQUIRED_NEW transaction type and try to do some logging and clean up before I leave my process to abort!