Java Message Service Concepts - The Java EE 6 Tutorial: Advanced Topics - page 382

sumer.close , and unsubscribe stands for a call to Session.unsubscribe .
Messages published while the subscriber is closed are received when the subscriber is
created again, so even though messages M2, M4, and M5 arrive while the subscriber is
closed, they are not lost.
See “ A Message Acknowledgment Example ” on page 406 , “ A Durable Subscription
Example ” on page 409 , and “ An Application That Uses the JMS API with a Session Bean ”
on page 416 for examples of Java EE applications that use durable subscriptions.
Using JMS API Local Transactions
You can group a series of operations into an atomic unit of work called a transaction . If
any one of the operations fails, the transaction can be rolled back, and the operations can
be attempted again from the beginning. If all the operations succeed, the transaction can
be committed.
In a JMS client, you can use local transactions to group message sends and receives. The
JMS API Session interface provides commit and rollback methods you can use
in a JMS client. A transaction commit means that all produced messages are sent and all
consumed messages are acknowledged. A transaction rollback means that all produced
messages are destroyed and all consumed messages are recovered and redelivered unless
they have expired (see “ Allowing Messages to Expire ” on page 362 ) .
A transacted session is always involved in a transaction. As soon as the commit or the
rollback method is called, one transaction ends and another transaction begins. Clos-
ing a transacted session rolls back its transaction in progress, including any pending sends
and receives.
In an Enterprise JavaBeans component, you cannot use the Session.commit and
Session.rollback methods. Instead, you use distributed transactions, described in
“ Using the JMS API in Java EE Applications ” on page 368 .
You can combine several sends and receives in a single JMS API local transaction. If you
do so, you need to be careful about the order of the operations. You will have no problems
if the transaction consists of all sends or all receives, or if the receives all come before the
sends. However, if you try to use a request/reply mechanism, in which you send a message
and then try to receive a reply to that message in the same transaction, the program will
hang, because the send cannot take place until the transaction is committed. The following
code fragment illustrates the problem:
Click here to view code image
// Don't do this!
outMsg.setJMSReplyTo(replyQueue);