Catching Some Exceptions (Not Others)
Any exception raised when a transaction is in progress will cause the transaction to fail, right? If a transaction is available and something happens, you’d want to roll everything back, wouldn’t you?
In Mule, you can sometimes choose not to and this blog post explains how.
Normally every exception will cause a roll back. Let’s say that we’re reading items off a JMS queue within a transaction, are going to process the message and write it out to a file. The message will contain a valid weather forecast or an empty forecast if conditions are unpredictable. The component we’re working (com.metoffice.WeatherReport)with will enrich the weather forecast, if one is available, or will throw an exception if the forecast is empty. Let’s also assume that we cannot change the implementation of this component.
Let’s review things.
1 – We read the message from JMS. Any transformers on the endpoint will be used and if they raise exceptions, we need to roll things back.
2 – Any routing patterns are applied. Any exception means we should roll back.
3 – The component com.metoffice.WeatherReport takes the message. If it raises an exception, this simply means that the forecast is empty. This sort of exception should not cause a rollback.
4 – The result of the component, if available, is written out to the outbound endpoint. Any exceptions in the routing mechanism or transformers should cause a rollback.
As you can see, there is just one case where an exception should be ignored by the transaction handling mechanism.
In Mule, this can be done by using the following configuration:
<default-service-exception-strategy> <commit-transaction exception-pattern="*"/> <rollback-transaction exception-pattern="org.mule.*"/> <jms:outbound-endpoint queue="dead.letter.queue"/> </default-service-exception-strategy>
The exception strategy is configured here with the following XML elements:
1 –
2 –
Note that this suggests that all exceptions will commit but since rolling back is more important than committing, the pattern for the
3 – In case of an exception, the message is routed to an alternative endpoint – the dead.letter.queue
If you enjoyed this post, make sure you subscribe to my RSS feed!
Tags: default-service-exception-strategy, exception, transaction
August 6th, 2009 at 9:33 PM
[...] This post was Twitted by aperepel [...]