(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
connector-quick-n-dirty-patch.zip
Description: Binary data
