O'Reilly - Java Message Service

Else, commit (that's what just happened):
else
session.commit( );
}
return;
Otherwise, just continue on and process the message.
Java Message Service
Point-to-point queues have the same transactional capabilities as publish-and-subscribe,
with one caveat: when a rollback( ) occurs on a QueueSession, the messages are placed
back on the queue. Because a queue may have multiple recipients, the messages could now
go to another consuming client. This may result in messages being processed out of order,
since the other client could have processed newer messages while the older messages were
being rolled back. This is an area where behavior may vary, depending on how your
vendor interprets the standard.
Finally, you may have noticed that we used Wholesaler and Retailer for this example
instead of their "Q" counterparts. This is because a publish-and-subscribe session and
point-to-point session cannot jointly particpate in a JMS transaction. JMS transactions
cannot span multiple sessions without the use of a JTA-compliant transaction manager (see
the next section, Section 6.4.3). We wanted to show the use of JMS as first-class
middleware in its own right, without using a supporting application server just to provide a
shared transaction between a p2p and a pub/sub session. The inability of p2p and pub/sub
sessions to share a transaction is a weakness in JMS that may be addressed in a future
version of the specification.
6.4.3 Distributed Transactions
Distributed systems sometimes use a two-phase commit (2PC) process that allows multiple
distributed resources to participate in one transaction. This typically involves an
underlying transaction manager that takes care of coordinating the prepare, commit, or
rollback of each resource participating in the transaction. In most cases, the resources
involved in the transaction are databases, but they can be other things, like JMS providers.
Transactions can be either local transactions or global transactions. Local transactions
involve work performed on a single resource: one database or JMS provider. Global
transactions involve work performed across several different resources, i.e., some
combination of databases and JMS providers. JMS provides transaction facilities for both
local and global transactions. The transacted sessions discussed previously are local
transactions in JMS; they involve a single JMS provider.
The 2PC protocol is designed to facilitate global transactions, transactions that span
multiple resources. As an example, an enterprise application may need to process
(consume and produce) messages as well as make changes to a database. In some cases,
the processing of messages and database updates needs to be treated as a single unit of
work, so that a failure to update the database or consume a message will cause the entire
unit of work to fail. This is the basic premise behind a transaction: all the tasks must
complete or fail together. To create a unit of work that spans different resources, the
resources must be able to cooperate with a transaction manager in a 2PC.
102