JBossDeveloper

"jhalliday" wrote:
The JCA should return the connection to the pool on transaction termination. Having an app call close() on a connection handle does not necessarily put it back in the pool. The track-connection-by-tx setting plays a part too. Such matters are really better off being discussed in the JCA forum.

"jhalliday" wrote:
Assuming its previously been closed by the app, yes. My understanding of JCA behaviour when track-connection-by-tx is set is that it will release a connection back into the pool only when it thinks that both the app and the tx are done with it. If either close() has not been called or the tx is not terminated, the connection is not eligible for reuse.

2008-07-30 07:22:07,421 TRACE [org.jboss.resource.connectionmanager.TxConnectionManager] getManagedConnection trackByTx=true tx=TransactionImple < jca-subordinate, BasicAction: a413888:a09:48905bb7:6f status: ActionStatus.RUNNING >

"jhalliday" wrote:
Hmm. It may be worth forcing 2PC just in case the JCA is doing the release in commit and failing to deal with the 1PC optimization. Failing that, throw together a test case that reproduces the problem and send it my way, I'll take a look when I get time.

Alright, here's a new twist. Forcing 2PC (for some reason, I had to modify BridgeParticipantAT to only return Prepared, despite changing my annotation attributes, somehow READONLY was still being set).

On commit(), I get an XAException. In particular, the Tx cannot be found.

 TransactionImple tx = TxImporter.getImportedTransaction(xid);

 if (tx == null)
 throw new XAException(XAException.XAER_INVAL);

10:14:34,256 INFO [STDOUT] 10:14:34,256 TRACE [ewsng/InboundBridge] stop(< 131075, 25, 64, 1-a413888:410:4890830a:31
10:14:37,334 INFO [STDOUT] 10:14:37,334 TRACE [ewsng/BridgeParticipantAT] prepare(Xid=< 131075, 25, 64, 1-a413888:410:4890830a:31
10:14:37,334 INFO [STDOUT] 10:14:37,334 DEBUG [ewsng/BridgeParticipantAT] prepare on Xid=< 131075, 25, 64, 1-a413888:410:4890830a:31 returning Prepared
10:14:38,381 INFO [STDOUT] 10:14:38,381 TRACE [ewsng/BridgeParticipantAT] commit(Xid=< 131075, 25, 64, 1-a413888:410:4890830a:31
10:14:40,365 INFO [STDOUT] 10:14:40,365 DEBUG [ewsng/BridgeParticipantAT] commit on Xid=< 131075, 25, 64, 1-a413888:410:4890830a:31 failed
javax.transaction.xa.XAException
 at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.commit(XATerminatorImple.java:82)
 at org.jboss.txbridge.BridgeParticipantAT.commit(BridgeParticipantAT.java:98)
 at com.arjuna.wst.messaging.engines.ParticipantEngine.executeCommit(ParticipantEngine.java:414)
 at com.arjuna.wst.messaging.engines.ParticipantEngine.commit(ParticipantEngine.java:137)
 at com.arjuna.wst.messaging.ParticipantProcessorImpl.commit(ParticipantProcessorImpl.java:95)
 at com.arjuna.webservices.wsat.handlers.ParticipantCommitHandler$1.executeTask(ParticipantCommitHandler.java:64)
 at com.arjuna.services.framework.task.TaskWorker.run(TaskWorker.java:65)
 at java.lang.Thread.run(Thread.java:595)

Looks like TxImporter is static, but that doesn't guarantee anything if JBoss has multiple classloaders in play. I'll see if I can make heads or tails of if two instances of this class are being loaded.

"jhalliday" wrote:
OK, I think maybe we are talking at cross purposes here. Forcing 2PC by not returning readonly should be done from the JTA subtransaction, not the BridgeParticipant. If the subtransaction returns readonly from prepare, it also throws away the tx at that point, which is why it can't subsequently be committed. See XATerminatorImple's prepare method. If you've hacked the bridge participant to rewrite an XA readonly from the terminator into a Prepared() response you've caused yourself a problem...

I'm paraphrasing here .. ;-) Somewhere, there's something akin to a setReadOnly() and I'm guessing its set from somewhere within the Spring or Hibernate code ...

Ah, OK. I didn't know that the XAResource would do that ... wouldn't there be a way to override that? What if every time you do a SELECT a trigger on the DB fires to insert or update a row? Wouldn't that need to be committed as part of the Tx that encapsulated the SELECT? Probably DB/trigger dependent, but I'm just curious ;-)