Well, the database pools are hemmoraging connections with the
latest CVS build. It looks like a trasaction problem. I put output in
the TxInterception and XAConnectionFactory, and I get something like this
when I call a method on a session bean that uses a database connection:
[Desktop] TX_REQUIRED for getPreferences
[Desktop] Begin tx
[XADataSource] org.jboss.minerva.xa.XADataSourceImpl created new
Connection (oracle.jdbc.driver.OracleConnection) with XAResource
org.jboss.minerva.xa.XAResourceImpl and XAConnection
org.jboss.minerva.xa.XAConnectionImpl.
[XADataSource] Enlisted 'org.jboss.minerva.xa.XAResourceImpl@78d244' with
transaction: tx:Xid:60
[XADataSource] Pool OptimaDB [4/4/10] gave out new object:
org.jboss.minerva.xa.XAConnectionImpl@594a88
[Desktop] commiting
[Desktop] Transaction 'tx:Xid:64' committing.
[Desktop] TxCapsule committing with 0 resources.
So the problem is, the TxInterceptor create a new Transaction,
namely #64. When the XAConnectionFactory runs the following code, it gets
Transaction #60. So the connection is registered with the wrong
transaction, and never gets committed. I suspect this is a problem where
there's a mismatch between the TxManager in JNDI and the TxManager that
the Container uses (used by the TxInterceptor), but I haven't been able to
track it down. Any help would be appreciated.
TransactionManager tm = (TransactionManager)ctx.lookup(tmJndiName);
if(tm.getStatus() != Status.STATUS_NO_TRANSACTION) {
Transaction trans = tm.getTransaction();
trans.enlistResource(con.getXAResource());
con.addConnectionEventListener(listener);
if(log != null) log.println("Enlisted '"+con.getXAResource()+"' with
transaction: "+trans);
Thanks,
Aaron
