Activity for Pafsanias Ftakas
-
Pafsanias Ftakas modified a comment on ticket #403
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....
-
Yes, this works fine, because everything happens on the same thread, as you pointed out. However, since we are orchastrating multiple DB2 statement executions within the same transaction, it is possible that the whole transaction might exceed the J2EE transaction timeout, even though individual calls have not exceeded the query timeout threshold.
-
It is indeed the case that the XA rollback is issued by a different thread. Here is what RedHat has to say on the subject: https://access.redhat.com/solutions/167033 (in case it helps). It seems that this is the way that Arjuna (RedHat's implementation of the JTA) is trying to deal with long running transactions and graceful release of resources in such cases. I will try to compare with logs where the transaction rolls back successfully (although as you say this happens on the same thread as the...
-
Hello again, Thank you for your comments. We are indeed trying to eliminate the MSGW as you suggest. However, following your advise, we tried to emulate a long running call to DB2 by means of locking (no MSGW condition involved). We lowered the transaction timeout on the part of the J2EE container down to 30 seconds. There was no query timeout involved. We removed the locking condition @ about 40 seconds past the beginning of the transaction. The behaviour was exactly the same as before. The JBoss...
-
Hello, I don't think I understand why you dismissed this problem as a server issue. We use the MSGW as a means to get into the situation where the transaction is taking more than 2 minutes, thereby causing the container application server to mark the transaction as rollback only. We do not care about the MSGW itself. The same situation might have arisen because of lock or contention in the back end that causes the transaction to exceed the 2 minute limit. Whatever the reason, when the container attempts...
-
XA rollback exception with stale transaction
-
Attempt to cancel SQL execution fails on MSGW
-
I tried the workaround you suggested, but I think it is just "hidding" the problem....
-
CREATE PROCEDURE CBSXASP (IN SP_SERVICE CHAR(50), INOUT SP_MESSAGE BLOB(128000),...
-
P.S. I just realized that you have a newer version of the jar. The problem still...
-
Crash when trying to retrieve blob from stored procedure parameter
1