Package org.springframework.jms.connection

Class JmsTransactionManager

java.lang.Object
org.springframework.transaction.support.AbstractPlatformTransactionManager
org.springframework.jms.connection.JmsTransactionManager
All Implemented Interfaces:
Serializable, InitializingBean, ConfigurableTransactionManager, PlatformTransactionManager, ResourceTransactionManager, TransactionManager
public class JmsTransactionManager extends AbstractPlatformTransactionManager implements ResourceTransactionManager, InitializingBean
PlatformTransactionManager implementation for a single JMS ConnectionFactory. Binds a JMS Connection/Session pair from the specified ConnectionFactory to the thread, potentially allowing for one thread-bound Session per ConnectionFactory.

This local strategy is an alternative to executing JMS operations within JTA transactions. Its advantage is that it is able to work in any environment, for example a standalone application or a test suite, with any message broker as target. However, this strategy is not able to provide XA transactions, for example in order to share transactions between messaging and database access. A full JTA/XA setup is required for XA transactions, typically using Spring's JtaTransactionManager as strategy.

Application code is required to retrieve the transactional JMS Session via ConnectionFactoryUtils.getTransactionalSession(jakarta.jms.ConnectionFactory, jakarta.jms.Connection, boolean) instead of a standard Jakarta EE-style ConnectionFactory.createConnection() call with subsequent Session creation. Spring's JmsTemplate will autodetect a thread-bound Session and automatically participate in it.

Alternatively, you can allow application code to work with the standard Jakarta EE-style lookup pattern on a ConnectionFactory, for example for legacy code that is not aware of Spring at all. In that case, define a TransactionAwareConnectionFactoryProxy for your target ConnectionFactory, which will automatically participate in Spring-managed transactions.

The use of CachingConnectionFactory as a target for this transaction manager is strongly recommended. CachingConnectionFactory uses a single JMS Connection for all JMS access in order to avoid the overhead of repeated Connection creation, as well as maintaining a cache of Sessions. Each transaction will then share the same JMS Connection, while still using its own individual JMS Session.

The use of a raw target ConnectionFactory would not only be inefficient because of the lack of resource reuse. It might also lead to strange effects when your JMS driver doesn't accept MessageProducer.close() calls and/or MessageConsumer.close() calls before Session.commit(), with the latter supposed to commit all the messages that have been sent through the producer handle and received through the consumer handle. As a safe general solution, always pass in a CachingConnectionFactory into this transaction manager's "connectionFactory" property.

Transaction synchronization is turned off by default, as this manager might be used alongside a datastore-based Spring transaction manager such as the JDBC DataSourceTransactionManager, which has stronger needs for synchronization.

Since:
1.1
Author:
Juergen Hoeller
See Also: