{@link org.springframework.transaction.PlatformTransactionManager} implementationfor a single JMS {@link javax.jms.ConnectionFactory}. Binds a JMS Connection/Session pair from the specified ConnectionFactory to the thread, potentially allowing for one thread-bound Session per ConnectionFactory.
NOTE: This class requires a JMS 1.1+ provider because it builds on the domain-independent API. Use the {@link JmsTransactionManager102} subclassfor a JMS 1.0.2 provider, e.g. when running on a J2EE 1.3 server.
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 {@link org.springframework.transaction.jta.JtaTransactionManager} as strategy.
Application code is required to retrieve the transactional JMS Session via {@link ConnectionFactoryUtils#getTransactionalSession} instead of a standardJ2EE-style {@link ConnectionFactory#createConnection()} call with subsequentSession creation. Spring's {@link org.springframework.jms.core.JmsTemplate}will autodetect a thread-bound Session and automatically participate in it.
Alternatively, you can allow application code to work with the standard J2EE-style lookup pattern on a ConnectionFactory, for example for legacy code that is not aware of Spring at all. In that case, define a {@link TransactionAwareConnectionFactoryProxy} for your target ConnectionFactory,which will automatically participate in Spring-managed transactions.
This transaction strategy will typically be used in combination with {@link SingleConnectionFactory}, which uses a single JMS Connection for all JMS access in order to avoid the overhead of repeated Connection creation, typically in a standalone application. Each transaction will then share the same JMS Connection, while still using its own individual JMS Session.
Transaction synchronization is turned off by default, as this manager might be used alongside a datastore-based Spring transaction manager such as the JDBC {@link org.springframework.jdbc.datasource.DataSourceTransactionManager}, which has stronger needs for synchronization.
@author Juergen Hoeller
@since 1.1
@see ConnectionFactoryUtils#getTransactionalSession
@see TransactionAwareConnectionFactoryProxy
@see org.springframework.jms.core.JmsTemplate