user manual

248 BES Developer’s Guide
JMS and Transactions
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.
The user's code should never use any XA APIs in JMS. The program should
look exactly as if the code is written like a normal JMS program and it is the
Container's responsibility to handle any XA handshakes. The only thing you
need to ensure is that you configured the <resource-ref> that points to the
JMS Connection factory JNDI object to use the XA variant. If it is non-XA, the
program still runs, but there are not any atomicity guarantees, in other words,
it is a local transaction.
Also note that for the Container to automatically handle the transaction
handshakes it is necessary to have the code run in a "container", either
appclient, EJB or web. A simple java client won't show the correct
characteristics, one has to write it as a J2EE application client instead. Also
make sure that all connection factories are looked up via a <resource-ref>.
This allows the Container to trap the JMS API calls and insert appropriate
hooks.
Note We handle the following case:
// transaction context exists
conn.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
...
sender.send( tm )
to mean the same as if the transaction context weren't there. We consider this
to mean "give me what I asked for since the first parameter is explicitly false".
This is not explicitly mentioned anywhere in the spec but this is in line with test
cases in the J2EE Compatibility Test Suite (CTS 1.3.1). It seems useful to
have this capability in a transaction you may want to send a log message
irrespective of the enclosing transaction's commit/rollback.
Multi resource access is also supported. Here we look at providing the
capability to do a unit of work which is composed of sending/receiving JMS
messages along with some other resource access. That is, it is desirable to be
able to write some code (an EJB for example) which does some work against
a resource (Oracle, SAP, whatever) and also puts a message into a queue
and the server provides transactional guarantees for that combination of work.
That is, either the work against Oracle is done AND the message is queued, or
something fails, and the work done against Oracle is rolled back AND the
message is not queued.
In code, we support having a method like this:
// business method in a session bean, Container marks the transaction
void doSomeWork()
{