I am trying to list the different possible transaction options and behavior
for a Message Driven that is also sending JMS messages as part of the logic
of its onMessage operation.
This subject has already been touched through multiple post in the mailing
list, but I did not find any consolidated version.
Here is what was able to determine so far. Please, feel free to comment,
especially if something is not accurate.
Thanks.
Container-managed transaction
=======================
- The trans-attribute of the onMessage operation can be set to
Required or NotSupported. I am not sure to understand the difference between
the two since, in both cases, it seems that according
to the EJB specification, the reading of incoming messages will be
done within a transaction created by the container. In the case of Jboss, it
seems that if NotSupported is used, the messages
are read in a transaction but not in a global XA one (no messages
can be sent as part of a global XA transaction from within the onMessage
method). Can I expect that this behavior will be the same
on all app servers?
- The connection factory of the input destination must be an XA
connection factory. This is not clearly stated by the spec, so I guess it is
up to each app server. In the case of Jboss, I can use the
<xa-connection>false</xa-connection> in the jboss.xml to specify
that it is not. In this case, the JBoss container will do a "regular" commit
on the JMS session. A global transaction is still created
and JMS messages can be sent from within onMessage in this global
transaction. When onMessage returns the global transaction is committed and
then the input message session is committed.
- According to EJB spec, any JMS session open within a global
transaction (open within a container managed transaction MDB) will be
enlisted in the global transaction and the createXXXSession
parameters (boolean transacted, int acknowledgeMode) are ignored. It
also means, I suppose, that the corresponding connectionFactory must be an
XA connection factory. If a non-XA connection
factory is used, the behavior is probably app server specific. In
the case of Jboss, if a non-XA connection factory is used (not JmsXA) the
JMS session is not enlisted automatically and this is the
responsibility of the onMessage code to do the commit (or abort) on
the JMS session (or to use auto-acknowledge JMS session).
- In the case of an exception thrown by onMessage (it is not
supposed to happen, but just in case), any global transaction will be
aborted. In the case the input message has been read in a regular JMS
transaction (Jboss specific when input destination connection
factory is not XA or when NotSupported is used for trans-attribute) then
this regular JMS transaction is also aborted.
Bean-managed transaction
====================
- This case is much simpler, a global transaction is never created
by the container. The input JMS message is acknowledge before onMessage is
called (according to the acknowledge-mode).
- JMS messages sent from the onMessage code are following the
regular JMS rules for transaction. Multiple messages can be sent within one
global transaction if this transaction is explicitly
created within the onMessage code (getUserTransaction) and provided
that XA connection factories are used.
Thomas
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
