MQ, XA and WLI

Question

I'm trying to use MQ in a WLI process (JPD) with full XA support, without success.
          My configuration is as follows:
          -Weblogic 8.1 SP3, running an Integration domain
          -Websphere MQ 5.3 CSD07, running on the same physical box (necessary for XA)
          -I have a startup class that loads the appropriate com.ibm.mq.jms.MQQueueConnectionFactory and com.ibm.mq.jms.Queue classes (pre-populated with the correct info) into the JNDI tree.
          -connection mode is set to binding for the local queue managers, required for XA.
          -we have a library that uses the pre-loaded QCF's and Queue's, wrapped as a Java Control, to use in the JPD's. (The library is used to interact with the equivalent C++ library that exists on OS/390, VMS, Windows and Unix(s).)
          -XA works fine with our Oracle JDBC connections, so I know that XA is enabled.
          Using either the library or the control in a non-transactional manner works fine, either from a JPD or EJB or Servlet. It can send and receive with no issues.
          But when trying to use this setup with XA, things go wrong.
          Behaviour is as follows:
          1. In a very simple JPD, without any explicit transaction boundaries (the JPD is the transaction), messages are placed on the queue as soon as the QueueSender.send() is executed, but left in an uncommitted state. That's what I expect. Once the JPD ends, the message remains in an uncommitted state (with no connection handles left open on the queue) and MQ eventually cleans up the uncommited message. (I've also tried the same using a perform node and the appropriate JMS code in it, bypassing afore-mentioned library, same result.)
          1a) Modifying the above behaviour a bit, if I call the QueueSender.close() method after the send(), the connection is indeed closed, but the message remains uncommitted. If I don't call the QueueSender.close() method, the connection stays open until the next garbage collection cycle, and the message remains uncommitted forever.
          2. I tried creating an explicit transaction around the node doing the send(), and received a java.io.NotSerializableException, since the MQ libraries (com.ibm.mq.jms.*) are not serialable.
          3. I tried out of desperation to create the control as a factory, same result as #1.
          4. I've looked at the MQControl, but it doesn't seem to do XA at all. As soon as the MQControl sent the message, the message was on the queue and committed, even though the process had ended. Throwing an exception later in the JPD did NOT cause the message to roll back. My conclusion (please prove me wrong!) is that the MQControl is not XA aware.
          Seems that in scenarios 1-3 MQ knows that the message is in a transaction (in a Syncpoint in MQ-speak) but is never recieving the commit.
          I really don't want to use the Foreign JMS provider, since I've got a lot of queues, and the filesystem-based JNDI tree is the only option I have to get at the MQ QCF's and Queues... and that's really ugly. I also don't want to use the Messaging Bridge, again because of the sheer number of queues, and the pain in configuring and maintaining this beast.
          Any ideas? What am I missing?
          thanks
          mike

Answer 1

Have you found any solution to your problem?
          I know that the WLI team deals often with MQ integration issues, and I know that MQ/XA integration is something that comes up often for them. Someone from WLI support should be able to help.
          One solution may be to use the WLI JMS control, using the IBM JMS API for MQSeries. As I understand it, this control supports XA. However, I'm not an WLI expert.
          If that fails, another solution woule be to use the JTA APi to enlist the MQ JMS provider directly. However, this can get tricky, but if you want to do it, you need to:
          -- Create XAConnection, and XASession objects for MQ when connecting
          -- Use weblogic.transaction.TransactionHelper to get access to the current Transaction object.
          -- Enlist the MQSeries XAResource object (which you get from the XASession object) with the transaction before sending.