Pafsanias Ftakas

It is interesting that you should say that. I wrote a little test program that uses the driver directly (no JCA), but uses the strategy that IronJacamar seems to take: when a (simulated) transaction timeout occurs, the xa_end and xa_rollback will take place on a different thread than the one where the xa_start was initiated from (essentially the thread on which the RollbackRunnable is running on, is the equivalent of the transaction reaper thread). Whenever I run this test, all connections and calls...

It is interesting that you should say that. I wrote a little test program that uses the driver directly (no JCA), but uses the strategy that IronJacamar seems to take: when a (simulated) transaction timeout occurs, the xa_end and xa_rollback will take place on a different thread than the one where the xa_start was initiated from (essentially the thread on which the RollbackRunnable is running one, is the equivalent of the transaction reaper thread). Whenever I run this test, all connections and calls...

It is interesting that you should say that. I wrote a little test program that uses the driver directly (no JCA), but uses the strategy that IronJacamar seems to take: when a (simulated) transaction timeout occurs, the xa_end and xa_rollback will take place on a different thread than the one where the xa_start was initiated from (essentially the thread on which the RollbackRunnable is running one, is the equivalent of the transaction reaper thread). Whenever I run this test, all connections and calls...

I attach two runs. In both cases I run the same scenario: a transaction is started, which calls a long running operation (it takes about 20 seconds) on IBM-i. The transaction timeout is set to 10 seconds. After 10 seconds the transaction reaper worker thread kicks in and attempts to stop the long running transaction. It fails to do so, so the jboss transaction runtime marks the transaction as rollback only and the thread it is running on as a zombie. Later on, on the thread that is executing the...

It has been a long time, but this problem has reared it head again. I figured out how to stop the reaper thread from effectively performing an interrupt at all. This has the result that on the reaper working thread, both xa_end and xa_rollback are called, and they are successful (ie, the communication reached the IBM-i and therefore no "orphaned transactions" are left on the DB2 side). This is all good. However, when a subsequent call comes along, something in the connection (?) is in an incorrect...

Please find attached the JBoss and Toolbox traces for the same scenario, but with the modified JDBC driver to bypass the issue with the tracing turned on. Also, I would like to inform you that we have opened an issue with RedHat on the same problem to see what the opinion from the side of the coordinator is. The people from RedHat have seen this thread. Unfortunately their reply needs a login in order to access it, so I wanted to share it with you in case it gives you some insight into the problem...

It turns out that turning off tracing did make a difference in the stack trace that we get: 12:34:39,676 WARN [org.jboss.jca.core.connectionmanager.listener.TxConnectionListener] (Transaction Reaper Worker 4) IJ000305: Connection error occured: org.jboss.jca.core.connectionmanager.listener.TxConnectionListener@263d0f5a[state=NORMAL managed connection=org.jboss.jca.adapters.jdbc.xa.XAManagedConnection@743c0faf connection handles=1 lastUse=1520418825099 trackByTx=true pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@1adc1f34...

I have to try not having JDBC tracing enabled to answer your question. I turned all tracing that I could think off "on", since I wanted to find out what was happening. Bear with us, we will test this tomorrow and I will get back to you....