BEA Weblogic Interview Question:

Why is my JMS work not part of a user transaction (i.e., called within a transaction but not rolled back appropriately)? How do I track down transaction problems?

Submitted by: Administrator

Usually this problem is caused by explicitly using a transacted session which ignores the external, global transaction by design (JMS spec requirement). A transacted JMS session always has its own inner transaction. It is not affected by any transaction context that the caller may have.

It may also be caused by using a connection factory that is configured with "UserTransactionsEnabled" set to false.
1. You can check if the current thread is in a transaction by adding these two import lines:
import javax.transaction.*
import weblogic.transaction.*;

and adding the following lines (i.e., just after the begin and just before every operation).

Transaction tran = TxHelper.getTransaction();
System.out.println(tran);
System.out.println(TxHelper.status2String(tran.getStatus()));

This should give a clear idea of when new transactions are starting and when infection is occurring.

2. Ensure that the thread sending the JMS message is infected with a transaction. Check that the code is not using a transacted session by setting the first parameter of createQueueSession or createTopicSession to false. Note that creating the connection and/or session is orthogonal to the transaction. You can begin your transaction before or after. You need only start the transaction before you send or receive messages.

3. Check that the UserTransactionsEnabled flag is explicitly set to true for the connection factory in the config.xml file since the default for user-configured connection factories for this value is false. If you are using one of the pre-configured connection factories they are set as follows:

weblogic.jms.ConnectionFactory disables user transactions so
don't use this one for the case where user transactions are
desired;

javax.jms.QueueConnectionFactory and
javax.jms.TopicConnectionFactory enable user transactions.

4. You can trace JTA operations by starting the server with this additional property:
-Dweblogic.Debug.DebugJMSXA=true
You should see trace statements like these in the log:
XA ! XA(3163720,487900) <RM-isTransactional() ret=true>
This can be used to ensure that JMS is infected with the transaction.
Submitted by: Administrator