The leak doesn’t appear when the transaction is commited.
After some investigation we found that because of fix made for jira https://hibernate.atlassian.net/browse/HHH-7910#icft=HHH-7910 the class SynchronizationCallbackCoordinatorTrackingImpl is delaying the rollback of a JTA transaction if the rollback is made by a different thread.
However in our case the JTA XA Remote transaction is always commited or rollbacked in a different thread and the delay operation is never executed because there is no additionial job to do in the thread that retrieve the session.
We also found that this behavior of delaying the rollback can be desactivated using hibernate propery
“hibernate.jta.track_by_thread” set to “false”. But this has the side effect of reactivating the bug described in https://hibernate.atlassian.net/browse/HHH-7910#icft=HHH-7910
Does anyone know this issue ? Is there solution of “hibernate.jta.track_by_thread” set to “false” is safe in our scenario ?
If a rollback is initiated through a different thread, it shouldn’t be a big problem IMO as you would get an exception anyway in the original thread when reaching the commit/rollback point in the main thread. I don’t understand though why you would commit a transaction from a different thread. How would the other thread know that the main thread is done and that a TX can safely commit? If there is some sort of synchronization i.e. the main thread triggers a condition that the other thread waits for, you could theoretically do all that in a safe way, but I would not recommend that.
If you look in the scenario (detailed in the uploaded image) the app1 (running on wildfly server 1) is the JTA XA coordinator of the transaction. As soon as the ejb call is executed in the second Wildfly server a remote transaction is enrolled inside the XA transaction but when the ejb Call returns, nothing is commit or rollback on app 2. It’s waiting on the JTA XA coordinator to receive either a 2PC prepare-commit order or a 2PC rollback.
The JTA XA coordinator (in that case Narayana) is using a custom remote protocol to order the remote ejb call on the app2 to execute the 2PC rollback. And the thread which is handling this rollback is not the main thread (it s not the one who execute the hibernate session call).
In that scenario app 2 has just to rollback the transaction (no additional work has to be done in the main thread)
Hope that my explanation helps you to understand my problem ?
From what I understand, the local transaction in which Hibernate participates should commit before return and thus cleanup the Session/EntityManager as well as do all callbacks. If the TX is rolled back by the coordinator later, there is nothing to cleanup in APP2 then. The coordinator only has to rollback the prepared TX in the DB.
