Hi,
I am having similar problems using the minerva xa pool with postgresql.
I also see a growing pool and I have some deadlock problems that
are probably due to unfinished transactions on connections that were
not returned to the free pool.
But I have been unable to see wrong transactions like you have.
Looking at the org.jboss.tm.TxManager class: begin(void) associates
the current thread with the new transaction, and commit(void)
drops the association. But commit(Transaction) does _not_ drop the
association.
Debugging a bit, I see the transaction started with TxManager.begin(void),
but the transaction is committed with TxManager.commit(Transaction),
leaving the thread associated with an old committed transaction.
When I subsequently obtain an xa connection outside of a transaction,
the connection does not return to the free pool on close.
If I add the line "threadTx.set(null);" to the start of
TxManager.commit(Transaction), the pool stops growing.
I don't know what the correct fix would be, but I hope this will help
you experts finding out.
Best Regards,
Ole Husgaard.
Aaron Mulder wrote:
>
> 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
