1
votes

I am using jms:message-driven-channel-adapter where I need to process the message that involves processing through multiple SI components and finally updating database or in some cases sending a JMS message.

How can I make this message processing fully transactional, meaning any error should result in message rolled back to JMS queue. I see that you can have a transaction-manager there but don’t see any example how to configure one for such case.

Also since I have concurrent-consumers set to higher number, so I will like to understand how it will behave in case of rolled back, will the message than immediately available to any other consumer or even same consumer?

Since its most likely that another consumer will fail too so how many times this message will be continue to be delivered (retried), how to deal with such scenarios.

Thank you very much

1

1 Answers

1
votes

Set acknowledge="transacted" and configure your JDBC transaction manager on the adapter; the JDBC transaction will be synchronized with the JMS transaction.

There is a small possibility that the JDBC tx might commit and JMS rolls back (if you lose connectivity for example), so you need to deal with redelivery and make your code idempotent; otherwise you'll need full XA.

See this article for a full explanation of options.

There's no control as to which consumer will get the redelivery.

Retries, DLQ etc are configured on your JMS broker.

EDIT:

Just to be clear, for this to work as described, the message channels must be direct channels (or pub-sub with no task executor), so the downstream operations (JMS, JDBC) run on the listener container's thread. It also assumes that those downstream operations use a JmsTemplate (with the listener's connection factory) - it will use the listener's Session - or a JdbcTemplate with the same transaction manager.

Spring Integration outbound adapters use those components internally.