> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury
> Sent: Monday, August 28, 2000 10:52 AM
> To: jBoss Developer
> Subject: RE: [jBoss-Dev] Transaction Woes
>
>
> 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.
sorry, I have put the non-JTA calls back to public.
I don't see direct calls to it though.
marc
>
> 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
> >
> >
>
>
>
