MQSeries.net :: View topic - Uncommitted transactions with extended transactional client

AKoerner

We have been testing the transactional behaviour of the new "extended transactional client" in a distributed environment:
- MQSeries 5.3 on server 1 (XAResource)
- WebLogic Server 8.1 on server 2 (XA TransactionManager)
- MQSeries extended transactional client on server 2
On server 2 we have configured an XAQueueConnectionFactory connecting to MQSeries on server 1 in client mode. Importing this XAQCF into WebLogic JNDI we can set up MQSeries as a "foreign JMS provider" in WebLogic Server for use by a MessageDrivenBean listening to messages on a remote MQSeries queue.

When we simulate a crash of the AppServer by killing it in the middle of a transaction we observe that the message just being processed is lost and won't be visible even after restarting the AppServer which acts as XA TransactionManager. (I think that's correct behaviour because the XA transaction has not yet entered the prepare-phase of the 2-phase-commit.) There are also no pending transactions in MQSeries which would be displayed by dspmqtrn. But qstatus shows 'uncom(true)' and after QueueManager restart the previously lost message will reappear -- much too late!

The strange thing is that our transaction test works fine in binding mode: After killing the AppServer the message reappears immediately -- long before AppServer restart.

So is it a bug of the extended transactional client?
Or did we miss any configuration details?

What we suspect is that we should configure some session or transaction timeout -- but how? And where: on the MQ server or on the "XA" client or in WLS or in the MDB?

Has anybody experience with the combination WebLogic Server 8.1 with WebSphere MQ 5.3 as foreign JMS provider using client mode?

Any hints would be greatly appreciated.
Andreas