O'Reilly - Java Message Service

XAResource jmsXA = session.getXAResource( );
/*
* Enlist the XAResource in the transaction. This adds the JMS
* resource to the global transaction.
*/
transaction.enlist(jmsXA);
// ... do some JMS work
/*
* Committing the global transaction will allow both the JDBC
* work (all updates and inserts) as well as the JMS work
* (all the message sends and receives) to be commited as a single
* unit of work. They all succeed or fail together.
*/
transaction.commit( );
Java Message Service
All XA-compliant resources ( JDBC or JMS) provide an XAResource object that is an
interface to the underlying resource (in JMS, the JMS provider). The XAResource object is
used by the TransactionManager to coordinate the 2PC commit. In the previous example,
the application associates the XAResource for the JDBC driver and the JMS provider with
the current transaction so that all the work performed using those resources is bound
together in one transaction. When the transaction is committed, all the work performed by
the JDBC connection and JMS session is committed. If the transaction had been rolled
back, all the work performed by the JDBC connection and JMS session would have been
rolled back. All the work performed across these two resources either succeeds together or
fails together.
An application server, such as an EJB server, may itself be a JMS client. In this case,
whether the interfaces are exposed depends on how the JMS server and the application
server are integrated. If the integration is hidden within the implementation, as is the case
with EJB, then the container may use the XA-compliant version of these objects directly.
Since the XA interfaces in JMS are not intended for application developers - they are
intended to be implemented by vendors - we will not go into them in detail in this book.
The important thing to understand is that JMS providers that implement the XA interfaces
properly can be used in a 2PC transaction. If your application server (i.e., EJB server)
supports 2PC, then these kinds of JMS providers can be used with other resources in
global transactions.
6.5 Lost Connections
When the network connection between the client and server is lost, a JMS provider must
make every reasonable attempt to re-establish the connection. In the event that the JMS
provider cannot automatically reconnect, the provider must notify the client of this
condition by throwing an exception when the client invokes a method that would cause
network traffic to occur. However, it is reasonable to expect that a JMS client may only be
a receiver using the MessageListener interface, and not a producer that makes any
outbound publish( ) or send( ) calls. In this case, the client is not invoking JMS methods
- it is just listening for messages - so a dropped connection won't be detected.
104