Can you please file two bug reports for these? (please assign them to me if possible)
If you can supply any kind of example to reproduce the second bug I would appreciate it. I find it mysterious because the code for LocalTx is supposed to return connections to the pool only after the transaction is committed. Anything else is a serious error. No workarounds should be necessary. thanks david jencks On 2002.10.08 04:08:24 -0400 Marko Štrukelj wrote: > > > (using: JBoss-3.0.3-src) > > > There is a typo in TransactionImpl disassociateCurrentThread(). > tx.associateCurrentThread() is called instead of > tx.disassociateCurrentThread() > > > > > There is another more annoying bug/feature. > When doing very intensive remote calls via statefull session, using the > database with user managed transactions I often get this error: > > > 2002-10-03 15:51:16,000 WARN >[org.jboss.resource.connectionmanager.LocalTxConnectionManager$LocalConnectionEventListener] > in Enlisting tx, trying to change tx. illegal state: old: > TransactionImpl:XidImpl [FormatId=257, GlobalId=brutus//233, > BranchQual=], new: TransactionImpl:XidImpl [FormatId=257, > GlobalId=brutus//234, BranchQual=], cel: > >org.jboss.resource.connectionmanager.LocalTxConnectionManager$LocalConnectionEventListener@1f8d0a4 > 2002-10-03 15:51:16,000 ERROR [STDERR] java.lang.IllegalStateException: > Trying to change Tx in enlist! > 2002-10-03 15:51:16,000 ERROR [STDERR] at > >org.jboss.resource.connectionmanager.LocalTxConnectionManager$LocalConnectionEventListener.enlist(LocalTxConnectionManager.java:309) > 2002-10-03 15:51:16,000 ERROR [STDERR] at > >org.jboss.resource.connectionmanager.LocalTxConnectionManager.managedConnectionReconnected(LocalTxConnectionManager.java:255) > 2002-10-03 15:51:16,000 ERROR [STDERR] at > >org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:534) > 2002-10-03 15:51:16,000 ERROR [STDERR] at > >org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:812) > 2002-10-03 15:51:16,000 ERROR [STDERR] at > >org.jboss.resource.adapter.jdbc.local.LocalDataSource.getConnection(LocalDataSource.java:102) > > > It only happens when there is severe concurent use of the database. But > it does happen a lot. > > > What happens is this: > > Thread 1: > > userTransaction.begin(); > Connection c=ds.getConnection(); // lets call this > Connection1 > > // ... use connection > > c.close(); // close connection > > // now don't commit transaction yet > > > > Thread 2: > userTransaction.begin(); > Connection c=ds.getConnection(); // KABOOOM! Exception > happens here. > > > > Exception happened because Connection1 was trying to be returned - the > same connection that was used by another thread. > > In the time between returning a connection to the pool and calling commit > on UserTransaction the same connection is checked out to another thread. > > > I played around with connector package and managed to reduce the problem > to virtually zero occurances. Now, the changes to the code I did are > quite crude and probably aren't in the spirit of code separation as was > envisaged (talk about casting interface to actual implementation and some > classes made public) so they are not suitable to be commited to cvs. > > > > The solution depends on InternalManagedConnectionPool.getConnection > method detecting in advance the condition that causes 'trying to change > Tx in enlist' exception. If ManagedConection is in 'transaction > collision' we simply find another one that is not. > > > To sum up the patch: > > - The main code is in InternalManagedConnectionPool.getConnection > > In order to make this code work and in order for the whole code to > compile other changes had to be made: > - method void setBaseConnectionManager2(BaseConnectionManager2 bcm) > was added to ManagedConnectionPool interface. > - It had to be implemented on several places in > JBossManagedConnectionPool.java > - It was implemented in InternalManagerConnectionPool > - Calls to setBaseConnectionManager2 had to be added in > BaseConnectionManager2 to pass reference to LocalTxConnectionManager. > > - LocalTxConnectionManager.LocalConnectionEventListener has new method: > boolean isTransactionCollisionFree() > > > > This quick patch is posted here more as an example of the kind of > checking that needs to be done in order to make the exception go away. > > > regards, > > -Marko > > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> > <HTML> > <HEAD> > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-2"> > <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12"> > <TITLE>JBoss 3.0.3 Bug: typo in TransactionImpl + trying to change Tx in > enlist exception</TITLE> > </HEAD> > <BODY> > <BR> > <BR> > > <P><FONT SIZE=2>(using: JBoss-3.0.3-src)</FONT> > </P> > <BR> > > <P><FONT SIZE=2>There is a typo in TransactionImpl > disassociateCurrentThread(). tx.associateCurrentThread() is called > instead of tx.disassociateCurrentThread()</FONT></P> > <BR> > <BR> > <BR> > > <P><FONT SIZE=2>There is another more annoying bug/feature.</FONT> > <BR><FONT SIZE=2>When doing very intensive remote calls via statefull > session, using the database with user managed transactions I often get > this error:</FONT></P> > <BR> > > <P><FONT SIZE=2>2002-10-03 15:51:16,000 WARN > >[org.jboss.resource.connectionmanager.LocalTxConnectionManager$LocalConnectionEventListener] > in Enlisting tx, trying to change tx. illegal state: old: > TransactionImpl:XidImpl [FormatId=257, GlobalId=brutus//233, > BranchQual=], new: TransactionImpl:XidImpl [FormatId=257, > GlobalId=brutus//234, BranchQual=], cel: > >org.jboss.resource.connectionmanager.LocalTxConnectionManager$LocalConnectionEventListener@1f8d0a4</FONT></P> > > <P><FONT SIZE=2>2002-10-03 15:51:16,000 ERROR [STDERR] > java.lang.IllegalStateException: Trying to change Tx in enlist! </FONT> > <BR><FONT SIZE=2>2002-10-03 15:51:16,000 ERROR [STDERR] at > >org.jboss.resource.connectionmanager.LocalTxConnectionManager$LocalConnectionEventListener.enlist(LocalTxConnectionManager.java:309)</FONT></P> > > <P><FONT SIZE=2>2002-10-03 15:51:16,000 ERROR [STDERR] at > >org.jboss.resource.connectionmanager.LocalTxConnectionManager.managedConnectionReconnected(LocalTxConnectionManager.java:255)</FONT></P> > > <P><FONT SIZE=2>2002-10-03 15:51:16,000 ERROR [STDERR] at > >org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:534)</FONT></P> > > <P><FONT SIZE=2>2002-10-03 15:51:16,000 ERROR [STDERR] at > >org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:812)</FONT></P> > > <P><FONT SIZE=2>2002-10-03 15:51:16,000 ERROR [STDERR] at > >org.jboss.resource.adapter.jdbc.local.LocalDataSource.getConnection(LocalDataSource.java:102)</FONT></P> > <BR> > > <P><FONT SIZE=2>It only happens when there is severe concurent use of the > database. But it does happen a lot. </FONT> > </P> > <BR> > > <P><FONT SIZE=2>What happens is this:</FONT> > </P> > > <P><FONT SIZE=2>Thread 1: </FONT> > </P> > > <P> <FONT > SIZE=2>userTransaction.begin(); </FONT> > <BR> <FONT SIZE=2>Connection > c=ds.getConnection(); // lets > call this Connection1 </FONT> > </P> > > <P><FONT SIZE=2>// ... use connection </FONT> > </P> > > <P> <FONT SIZE=2>c.close(); // > close connection </FONT> > </P> > > <P><FONT SIZE=2>// now don't commit transaction yet </FONT> > </P> > <BR> > <BR> > > <P><FONT SIZE=2> Thread 2: > </FONT> > <BR><FONT >SIZE=2> > userTransaction.begin(); </FONT> > <BR><FONT >SIZE=2> > Connection c=ds.getConnection(); // KABOOOM! Exception happens here. > </FONT> > </P> > <BR> > <BR> > > <P><FONT SIZE=2>Exception happened because Connection1 was trying to be > returned - the same connection that was used by another thread.</FONT> > </P> > > <P><FONT SIZE=2>In the time between returning a connection to the pool > and calling commit on UserTransaction the same connection is checked out > to another thread.</FONT></P> > <BR> > > <P><FONT SIZE=2>I played around with connector package and managed to > reduce the problem to virtually zero occurances. Now, the changes to the > code I did are quite crude and probably aren't in the spirit of code > separation as was envisaged (talk about casting interface to actual > implementation and some classes made public) so they are not suitable to > be commited to cvs.</FONT></P> > <BR> > <BR> > > <P><FONT SIZE=2>The solution depends on > InternalManagedConnectionPool.getConnection method detecting in advance > the condition that causes 'trying to change Tx in enlist' exception. If > ManagedConection is in 'transaction collision' we simply find another one > that is not.</FONT></P> > <BR> > > <P><FONT SIZE=2>To sum up the patch:</FONT> > </P> > > <P><FONT SIZE=2>- The main code is in > InternalManagedConnectionPool.getConnection</FONT> > </P> > > <P><FONT SIZE=2>In order to make this code work and in order for the > whole code to compile other changes had to be made:</FONT> > <BR><FONT SIZE=2>- method void > setBaseConnectionManager2(BaseConnectionManager2 bcm) was added to > ManagedConnectionPool interface.</FONT> > <BR><FONT SIZE=2>- It had to be implemented on several places in > JBossManagedConnectionPool.java</FONT> > <BR><FONT SIZE=2>- It was implemented in > InternalManagerConnectionPool</FONT> > <BR><FONT SIZE=2>- Calls to setBaseConnectionManager2 had to be added in > BaseConnectionManager2 to pass reference to > LocalTxConnectionManager.</FONT></P> > > <P><FONT SIZE=2>- LocalTxConnectionManager.LocalConnectionEventListener > has new method: boolean isTransactionCollisionFree()</FONT> > </P> > <BR> > <BR> > > <P><FONT SIZE=2>This quick patch is posted here more as an example of the > kind of checking that needs to be done in order to make the exception go > away.</FONT></P> > <BR> > > <P><FONT SIZE=2>regards,</FONT> > </P> > > <P><FONT SIZE=2>-Marko</FONT> > </P> > > <P><FONT FACE="Arial" SIZE=2 COLOR="#000000"></FONT> > > </BODY> > </HTML> > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
