web server - Borland Technical Publications

JMS and Transactions
sessions on behalf of a bean, the parameters of the createQueueSession(boolean
transacted,int acknowledgeMode) and createTopicSession(boolean transacted, int
acknowledgeMode) methods are ignored. It is recommended that the Bean Provider
specify that a session is transacted, but provide 0 for the value of the
acknowledgment mode.
The Bean Provider should not use the JMS acknowledge() method either within a
transaction or within an unspecified transaction context. Message acknowledgment in
an unspecified transaction context is handled by the container. Section 17.6.5
describes some of the techniques that the container can use for the implementation
of a method invocation with an unspecified transaction context.
Avoiding use of the JMS request/reply paradigm and JMS acknowledge() method is
equally relevant for other J2EE components such as application clients, as it is to EJB
bean code. In addition to rules described above, application code should not use any
JMS XA APIs. The program should look exactly as if the code is written in a nontransactional
JMS program. It is the Container's responsibility to handle any XA
handshakes required when a global transaction is active. The only configuration
required is that deployment descriptor element , with reference to the
JMS Connection factory JNDI object, be set up to use the XA variant. If it is non-XA,
the program still runs, but there are no atomicity guarantees, in other words, it is a local
transaction. Also note that for BES to automatically handle the transaction handshakes
it is necessary to have the application run in a Container, either EJB, Web or appclient.
For example, a java client with no JMS XA API calls will not have its JMS activity
participate in a global transaction, one has to write it as a J2EE application client
instead. Also make sure that all connection factories are looked up through deployment
descriptor element . This allows the Container to trap the JMS API calls
and insert appropriate hooks.
Lets examine in more detail the following sentences extracted from the EJB 2.0
specification:
Because the container manages the transactional enlistment of JMS sessions on
behalf of a bean, the parameters of the createQueueSession(boolean transacted,int
acknowledgeMode) and createTopicSession(boolean transacted, int acknowledgeMode)
methods are ignored. It is recommended that the Bean Provider specify that a session
is transacted, but provide 0 for the value of the acknowledgment mode.
The assumption here is that messages produced/consumed by JMS sessions should
be included as part of the unit of work maintained by a global transaction, should a
global transaction be active. In order for transactional enlistment to occur, the parent
connection factory of connections on which createQueueSession() or
createTopicSession() are invoked must be defined as a
javax.jms.XAQueueConnectionFactory or javax.jms.XATopicConnectionFactory,
respectively. That is, the value for of J2EE deployment descriptor element
, with definition of JMS connection factory to be used for the J2EE
component, must be either javax.jms.XAQueueConnectionFactory or
javax.jms.XATopicConnectionFactory. If the connection factory has a non XA connection
factory , the program still runs but work performed on JMS sessions will not
be included in the global transaction; in this case the transacted and acknowledgeMode
parameters will influence the behavior of message production/consumption.
Chapter 23: Using JMS 217