Return value of enlistResource is ignored

[renebos99]

In the class org.messaginghub.pooled.jms.pool.PooledXAConnection, the method enlistResource of TransactionManager is invoked, but the return value of this method is ignored. The return value is a boolean; accoriding to the spec, it is true if the resource was enlisted, and false otherwise.
We are using the PooledXAConnection in combination with the Narayana transaction manager (org.jboss.narayana.jta:narayana-jta:5.12.7.Final). This implementation sometimes returns false for enlistResource if a resource is not available (in such a case, the transaction is marked as rollback-only). Since this return value is not checked, the processing continues despite the absence of a working transaction. In our case, this has lead to situations where messages could not be processed and were lost.

It would be good to check the return value of enlistResource, and perform appropriate actions if the return value is false.

Stack trace, in case it can be useful:

ARJUNA016061: TransactionImple.enlistResource - XAResource.start returned: XAException.XAER_RMFAIL for < formatId=131077, gtrid_length=50, bqual_length=36, tx_uid=0:ffffac1edcbf:-3c0b9c4d:651eb4d8:225e2, node_name=grnapj0080linprdduonl8, branch_uid=0:ffffac1edcbf:-3c0b9c4d:651eb4d8:225e6, subordinatenodename=null, eis_name=unknown eis name >: javax.transaction.xa.XAException: The method 'xa_start' has failed with errorCode '-7'.
	at com.ibm.mq.jmqi.JmqiXAResource.start(JmqiXAResource.java:1019)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:661)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:422)
	at org.messaginghub.pooled.jms.pool.PooledXAConnection.createSession(PooledXAConnection.java:72)
	at org.messaginghub.pooled.jms.JmsPoolConnection.createSession(JmsPoolConnection.java:194)
	at org.springframework.jms.support.JmsAccessor.createSession(JmsAccessor.java:214)
	at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.access$200(AbstractPollingMessageListenerContainer.java:78)
	at org.springframework.jms.listener.AbstractPollingMessageListenerContainer$MessageListenerContainerResourceFactory.createSession(AbstractPollingMessageListenerContainer.java:509)
	at org.springframework.jms.connection.ConnectionFactoryUtils.doGetTransactionalSession(ConnectionFactoryUtils.java:328)
	at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:294)
	at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:246)
	at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1237)
	at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1227)
	at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:1120)
	at java.lang.Thread.run(Thread.java:750)

[tabish121]

My general advice would be not to mix XA connection work and a connection pool.