Invalidate JMS Session if xa enlistment throws an exception

[nielsm5]

Right now, (using the 1.x branch) when an enlistment fails the PooledXAConnection#createSession(boolean, int) closes the JmsPooledXASessionSynchronization which in turn closes the JmsPoolSession. (Which is good!)
However in the JmsPoolSession#cleanupSession() when there is no JMS exception, it simply returns false, causing the #close() method to return the object back to the pool instead of invalidating it. I understand the thought that since nothing really happened it should be safe to use, but in our case it looks like the XAResources are being reused as well as they are bound to the session.

I was wondering if this is the expected path to traverse since there was an exception, just not in a producer/consumer/browser, but during the enlistment. I've got a bit of our stacktrace in case it might come in handy;

javax.transaction.xa.XAException: null
	at com.tibco.tibjms.TibjmsXAResource.buildXAException(TibjmsXAResource.java:802) ~[tibjms-8.6.0.jar:8.6.0]
	at com.tibco.tibjms.TibjmsXAResource.buildXAException(TibjmsXAResource.java:783) ~[tibjms-8.6.0.jar:8.6.0]
	at com.tibco.tibjms.TibjmsXAResource.startV2(TibjmsXAResource.java:212) ~[tibjms-8.6.0.jar:8.6.0]
	at com.tibco.tibjms.TibjmsXAResource.start(TibjmsXAResource.java:240) ~[tibjms-8.6.0.jar:8.6.0]
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:661) [narayana-jta-5.12.7.Final.jar:5.12.7.Final (revision: bd3d5)]
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:422) [narayana-jta-5.12.7.Final.jar:5.12.7.Final (revision: bd3d5)]
	at org.messaginghub.pooled.jms.pool.PooledXAConnection.createSession(PooledXAConnection.java:84) [pooled-jms-1.2.7.jar:?]
	at org.messaginghub.pooled.jms.JmsPoolConnection.createSession(JmsPoolConnection.java:194) [pooled-jms-1.2.7.jar:?]

[tabish121]

It's probably better for the pool to toss out the session if anything other than the happy path occurs here however my general advice it to not use pooling when interacting with XA transactions as there's just only so much the pool can do to manage these sorts of scenarios given the lack of general visibility into what is going on under the covers.

I've stated before that I don't intend to release more from the 1.x series though so my suggestion is to move onto later 2.x or 3.x release which are up to date with the current Jakarta JMS APIs

[nielsm5]

I'm aware, I've seen/thoroughly read the other related issues, which you have kindly backported to the 1.x and 2.x !!

But unfortunately my question remains, as I've compared the code against the 3.x/main branch, and it's identical.
Since the code invalidates the session when (almost?) every other exception occurs, I was wondering if this particular flow is intended or if it could be improved 😄. Which is also the reason why I've created a discussion and not an issue.

[tabish121]

I may be possible to change the code to invalidate here on any error, but the basic advice remains, don't use pooling with XA. You are finding these issues because you choose to ignore that advice.

[nielsm5]

I understand your reasoning completely, though saying that I've seen many (proprietary) implementations which do allow XA pooling (as well as ActiveMQ where this project was originally forked from). XA can be a true nightmare, I'm well aware!

We have quite an extensive test set, and are well aware of the risks. For us the pro's outweigh the con's. And honestly, the fact that this is the only (real) problem we've encountered in the past years, says something about how well written, documented, tested and simply exceptional this project is. Take pride! Don't brush it off with 'you really shouldn't pool XA connections' 🥇

[tabish121]

I just released a new version of 3.x 2.x and 1.x with a change to invalidate any session if the enlistment doesn't seem to have travelled the happy path. This may resolve your issue but there isn't a way to test that here.

[nielsm5]

Thanks for the incredibly fast responses and fix/release. Quickly linking 1b8a8a5 here, so others may be able to find this thread in the future.