CachingConnectionFactory

SingleConnectionFactory subclass that adds javax.jms.Session caching as well javax.jms.MessageProducer caching. This ConnectionFactory also switches the "reconnectOnException" property to "true" by default, allowing for automatic recovery of the underlying Connection.

By default, only one single Session will be cached, with further requested Sessions being created and disposed on demand. Consider raising the "sessionCacheSize" value in case of a high-concurrency environment.

When using the JMS 1.0.2 API, this ConnectionFactory will switch into queue/topic mode according to the JMS API methods used at runtime: createQueueConnection and createTopicConnection will lead to queue/topic mode, respectively; generic createConnection calls will lead to a JMS 1.1 connection which is able to serve both modes.

NOTE: This ConnectionFactory requires explicit closing of all Sessions obtained from its shared Connection. This is the usual recommendation for native JMS access code anyway. However, with this ConnectionFactory, its use is mandatory in order to actually allow for Session reuse.

Note also that MessageConsumers obtained from a cached Session won't get closed until the Session will eventually be removed from the pool. This may lead to semantic side effects in some cases. For a durable subscriber, the logical Session.close() call will also close the subscription. Re-registering a durable consumer for the same subscription on the same Session handle is not supported; close and reobtain a cached Session first.

ChainedExceptionListener

Implementation of the JMS ExceptionListener interface that supports chaining, allowing the addition of multiple ExceptionListener instances in order.

ConnectionFactoryUtils

Helper class for managing a JMS javax.jms.ConnectionFactory, in particular for obtaining transactional JMS resources for a given ConnectionFactory.

Mainly for internal use within the framework. Used by org.springframework.jms.core.JmsTemplate as well as org.springframework.jms.listener.DefaultMessageListenerContainer.

DelegatingConnectionFactory

javax.jms.ConnectionFactory implementation that delegates all calls to a given target javax.jms.ConnectionFactory, adapting specific create(Queue/Topic)Connection calls to the target ConnectionFactory if necessary (e.g. when running JMS 1.0.2 API based code against a generic JMS 1.1 ConnectionFactory, such as ActiveMQ's PooledConnectionFactory).

This class allows for being subclassed, with subclasses overriding only those methods (such as #createConnection()) that should not simply delegate to the target ConnectionFactory.

Can also be defined as-is, wrapping a specific target ConnectionFactory, using the "shouldStopConnections" flag to indicate whether Connections obtained from the target factory are supposed to be stopped before closed. The latter may be necessary for some connection pools that simply return released connections to the pool, not stopping them while they sit in the pool.

JmsResourceHolder

JMS resource holder, wrapping a JMS Connection and a JMS Session. JmsTransactionManager binds instances of this class to the thread, for a given JMS ConnectionFactory.

Note: This is an SPI class, not intended to be used by applications.

JmsTransactionManager

org.springframework.transaction.PlatformTransactionManager implementation for a single JMS 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.

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 org.springframework.transaction.jta.JtaTransactionManager as strategy.

Application code is required to retrieve the transactional JMS Session via ConnectionFactoryUtils#getTransactionalSession instead of a standard Java EE-style ConnectionFactory#createConnection() call with subsequent Session creation. Spring's 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 Java 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 org.springframework.jdbc.datasource.DataSourceTransactionManager, which has stronger needs for synchronization.

SmartConnectionFactory

Extension of the javax.jms.ConnectionFactory interface, indicating how to release Connections obtained from it.

TransactionAwareConnectionFactoryProxy

Proxy for a target JMS javax.jms.ConnectionFactory, adding awareness of Spring-managed transactions. Similar to a transactional JNDI ConnectionFactory as provided by a Java EE application server.

Messaging code which should remain unaware of Spring's JMS support can work with this proxy to seamlessly participate in Spring-managed transactions. Note that the transaction manager, for example JmsTransactionManager, still needs to work with the underlying ConnectionFactory, not with this proxy.

Make sure that TransactionAwareConnectionFactoryProxy is the outermost ConnectionFactory of a chain of ConnectionFactory proxies/adapters. TransactionAwareConnectionFactoryProxy can delegate either directly to the target factory or to some intermediary adapter like UserCredentialsConnectionFactoryAdapter.

Delegates to ConnectionFactoryUtils for automatically participating in thread-bound transactions, for example managed by JmsTransactionManager. createSession calls and close calls on returned Sessions will behave properly within a transaction, that is, always work on the transactional Session. If not within a transaction, normal ConnectionFactory behavior applies.

Note that transactional JMS Sessions will be registered on a per-Connection basis. To share the same JMS Session across a transaction, make sure that you operate on the same JMS Connection handle - either through reusing the handle or through configuring a SingleConnectionFactory underneath.

Returned transactional Session proxies will implement the SessionProxy interface to allow for access to the underlying target Session. This is only intended for accessing vendor-specific Session API or for testing purposes (e.g. to perform manual transaction control). For typical application purposes, simply use the standard JMS Session interface.

UserCredentialsConnectionFactoryAdapter

An adapter for a target JMS javax.jms.ConnectionFactory, applying the given user credentials to every standard createConnection() call, that is, implicitly invoking createConnection(username, password) on the target. All other methods simply delegate to the corresponding methods of the target ConnectionFactory.

Can be used to proxy a target JNDI ConnectionFactory that does not have user credentials configured. Client code can work with the ConnectionFactory without passing in username and password on every createConnection() call.

In the following example, client code can simply transparently work with the preconfigured "myConnectionFactory", implicitly accessing "myTargetConnectionFactory" with the specified user credentials.

 <bean id="myTargetConnectionFactory" class="org.springframework.jndi.JndiObjectFactoryBean"> <property name="jndiName" value="java:comp/env/jms/mycf"/> </bean> <bean id="myConnectionFactory" class="org.springframework.jms.connection.UserCredentialsConnectionFactoryAdapter"> <property name="targetConnectionFactory" ref="myTargetConnectionFactory"/> <property name="username" value="myusername"/> <property name="password" value="mypassword"/> </bean>

If the "username" is empty, this proxy will simply delegate to the standard createConnection() method of the target ConnectionFactory. This can be used to keep a UserCredentialsConnectionFactoryAdapter bean definition just for the option of implicitly passing in user credentials if the particular target ConnectionFactory requires it.

SynchedLocalTransactionFailedException

Exception thrown when a synchronized local transaction failed to complete (after the main transaction has already completed).