Jurgen Holler and JMS and JCA
Day Three (Full Day Two) here at The Spring Experience, and the morning session has Jurgen Holler talking about Spring's support for JMS and JCA. He knows his stuff. We're going over the standard synchronous
Spring 2.0 has full support for asynchronous message receiving with POJOs. This is the elusive Message Driven POJO, important when Message Driven Beans (MDBs) aren't available.
An important note about the
For asynchronous message handling, you can either use
Enter Spring 2.0's new message listener container. You have the option of implementing
The Spring provided message container is the
Note that XA transaction handling provided by the container starts the transaction with message reception. That is, the message reception is within a transaction.
Much of this is possible through the new
JmsTemplate
, useful when you're not running an asynchronous JMS listener.Spring 2.0 has full support for asynchronous message receiving with POJOs. This is the elusive Message Driven POJO, important when Message Driven Beans (MDBs) aren't available.
An important note about the
JmsTemplate
is that it fetches a Connection
for every request. In a managed environment, this is OK, because the container will pool Connections
. However, in a non-managed environment, be sure that the ConnectionFactory
is pooling connections.For asynchronous message handling, you can either use
MessageListener
and manually register it with the Session
, or use J2EE's Message Driven Beans. In either case, you are using a framework interface (MessageListener
) which is not POJO compliant. Also, typically if you want XA and asynchronous message reception, you need to use MDBs.Enter Spring 2.0's new message listener container. You have the option of implementing
MessageListener
, or the Spring specific SessionAwareMessageListener
. As it sounds, you get a onMessage(Message, Session)
method. This is useful for sending reply messages, and you're able to thrown JMSException.The Spring provided message container is the
DefaultMessageListenerContainer
. It supports XA message reception, works with all JMS providers, simply uses MessageListener
and MessageConsumer
facilities. However, it does create one thread per consumer, which is forbidden by the J2EE contract. However, you may still do this and usually doesn't harm much.Note that XA transaction handling provided by the container starts the transaction with message reception. That is, the message reception is within a transaction.
SimpleMessageListenerContainer
is an alternative container, but does not support XA message reception and does not create custom threads. This is useful outside of a container.ServerSessionMessageListenerContainer
uses JMS's ServerSessionPool
, which is a SPI into the JMS Server. However, not very useful in J2EE containers, as the spec forbids the use of ServerSessionPool
. Also does not use XA transactions.Much of this is possible through the new
TaskExecutor
abstraction, for creation of custom threads. Three different implementations including a ConcurrentTaskExecutor
which uses JDK1.5's ThreadPoolExecutor
or WorkManagerTaskExecutor
which is for modern J2EE containers like BEA WebLogic 9 or IBM WebSphere 6. This executor uses the CommonJ WorkManager abstraction, allowing J2EE applications to formally and correctly use threads from within the container (forbidden by the spec). However, CommonJ is not a JSR, but is supported by BEA and IBM.DefaultMessageListenerContainer
is the recommended container, useful for most needs.