Poller transactional functionality, checked exceptions and rollback rules

[mehiel]

Lets say I have two Pollable[Jms]Channels and a ServiceActivator between them with a transactional poller with atomikos JTA transaction management (xa because of jms+db actions in the same flow). Is there any way to set rollback rules for exceptions raised within this transaction? Is there any way to not rollback on checked exceptions raised by this ServiceActivator?

From both documentation and source code I think that the answer is no. Poller parser uses o.s.t.i.DefaultTransactionAttribute as a default. Making parser read rollback-for and no-rollback-for attributes and build a o.s.t.i.RuleBasedTransactionAttribute is easy but...

...on the other side o.s.i.h.MethodInvokingMessageProcessor and several endpoints wrap the thrown exception into o.s.i.MessagingException (and others from this inheritence tree more specific to the endpoint like o.s.i.MessageTransformationException). So simply by making transaction attribute rule based gives me nothing. MessagingException is-a RuntimeException and the cause is not in the criteria for default rule matching of the spring framework.

What about a customized SIAwaredRuleBasedTransactionAttribute that applies those rules in the first inner cause that is not instanceof MessagingException. It sounds promising for my needs and maybe some similar cases but it may be not that flexible and a lot complex to understand for some more general usage.

What do you think? I am about to give it a try but I'd like to hear your opinion for something like this. Is it the right approach to avoid rollback on some exceptions, if you have something else to suggest you are welcome to enlighten me.

Regards,
Aggelos

[fngaserin]

I've been looking around regarding to this issue too. I have a scenario where the service activator is listening to a message-driven queue. However, during processing in the service activator, there's a checked exception thrown on certain condition. According to the transaction management, the transaction will not rollback. However, whenever the exception is thrown, the listener treat it as an unhandled exception, therefore rethrow the exception as a MessageHandlingException, which is a RuntimeException. Finally, the runtime exception will rollback the whole transaction.

Is there a workaround to this?

[oleg.zhurakousky]

I am not sure I understand. If its checked exception why not just handle it in the handler?Everything that is thrown from the handler is assumed to be unknown and un-expedted thus converted to ME.