Local JTA keeps polling committed transaction

[burdeasa]

I am testing with JBoss Application Server 4.0.5 (default config) and JBoss Transactions 4.2.2 (Local JTA).

I tested an outbound recovery scenario with a JCA 1.5 resource adapter named DTPRA. The XAResource for DTPRA is not serializable, so I have implemented a XAResourceRecovery object. I have two instances of this resource adapter deployed, named "dtpra" and "dtpra1".

I tested the following:
1) Open connection to dtpra and dtpra1
2) Send a request to dtpra and dtpra1 in a transaction
3) Kill the Application Server process just before the XAResource.commit call for dtpra1 returns
4) Restart JBoss to perform recovery

So, in this scenario, both dtpra and dtpra1 have committed the transaction and removed their log records since the transaction is committed. However, JBoss Transactions still has a log record for the transaction.

After restarting JBoss, I get messages like the following in the JBoss server.log file:

2006-12-08 10:32:35,563 WARN [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] Could not find new XAResource to use for recovering non-serializable XAResource < 131075, 27, 25, 1--3fc02a9f:b45:45798238:52-3fc02a9f:b45:45798238:55 >

2006-12-08 10:32:35,563 WARN [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] Could not find new XAResource to use for recovering non-serializable XAResource < 131075, 27, 25, 1--3fc02a9f:b45:45798238:52-3fc02a9f:b45:45798238:58 >

These messages occur with every scan. I left JBoss running over night, thinking that eventually the WARN messages would stop because of an expiration scan, but the messages continued. I stopped and restarted JBoss again in the morning to ensure that an expiration scan occurred, but still the messages continued.


I reran the same test using JBoss Application Server 4.0.5 (all config) and JBoss Transactions 4.2.2 (Distributed JTA). In this case, I received messages like the following during recovery:

2006-12-08 11:01:29,619 WARN [jacorb.poa] POA RootPOA rid: 348 opname: _is_a _invoke: object id not previously generated!
2006-12-08 11:01:29,635 WARN [jacorb.poa] POA RootPOA rid: 346 opname: getCurrentStatus _invoke: object id not previously generated!

These messages occurred for about 6 scans, then I got:

2006-12-08 11:04:24,961 INFO [com.arjuna.ats.jts.logging.loggerI18N] [com.arjuna.ats.internal.jts.recovery.transactions.TransactionCache_4] [com.arjuna.ats.internal.jts.recovery.transactions.TransactionCache_4] - Transaction -3fc02a9f:d28:45798b47:7e assumed complete - will not poll any more

In summary:
Local JTA kept polling for at least 14 hours, and showed no signs of stopping. The Distributed JTA stopped after a few minutes, as I would have expected.

[marklittle]

Thanks, we'll take a look.

[marklittle]

The situations you describe are subtly different. Without going into too much detail, basically the local JTA transaction has a "direct" reference to your non-serializable XAResource in its log. In the JTS case, there is a reference to a JTS/OTS CosTransactions::Resource. OTS recovery kicks in and we traverses a different path and recovery assumes, after a finite period of time, that because it can't contact the Resource then it has completed. The recovering coordinator only has to try to re-create a CosTransactions::Resource, so your XAResource is never touched directly by this coordinator.

In the JTA case it tries to create a new instance of the XAResource because that's what it has in the log (the "direct" reference I mentioned above). This fails becuase you don't return anything now. The code assumes this is a transient and keeps trying (forever). XAResources registered with the JTS coordinator "directly" will behave in the same way.

This is a roundabout way of saying that the behaviour you expect to see and are seeing is because of slightly different circumstances. We can look to make local JTA (and JTS) behave similarly in this case in a subsequent release of JBossTS.