Ok the "disassociation" was one level up in commit(). Even though the
commit(Tx) is not part of JTA's TransactionManager I have moved the try
finally block one level down to the commit(tx) and rollback(tx) calls to
make sure we don't miss anybody. I have also made the non-JTA calls
protected.
marc
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Ole Husgaard
> Sent: Monday, August 28, 2000 9:47 AM
> To: jBoss Developer
> Subject: Re: [jBoss-Dev] Transaction Woes
>
>
> 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
>
>
