Please open a bug, and we will get this taken care of. I do have one question,Aries library, on which call does it expect to return the connection to the pool? XAConnection.close() or XAConnection.getConnection().close(); ?
On Tue, Mar 25, 2014 at 6:05 AM, Jonathan Pierce <jondavid...@gmail.com>wrote: > I am trying to use the tomcat jdbc pool library (outside of tomcat) > along with the Apache Aries Transaction library in an OSGi environment > to handle distributed transactions. > > One of the classes (XADataSourceEnlistingWrapper) provided by the > Aries Transaction wrappers library is a DataSource wrapper that auto > enlists connections. > > It appears that the Aries class is trying to call > XAConnection.getConnection with the expectation that the returned > Connection object will recycle connections when the close() method is > called (i.e. return the connection to the pool) > > However, in the tomcat jdbc pooling library > PooledConnection.getConnection() (and by extension > XAConnection.getConnection()) seems to be returning the physical > connection. So the physical connection is getting closed without > being returned to the pool and I'm getting exceptions saying the pool > is empty after a few requests. > > It looks like one of these libraries is implementing the interface > wrong (or its entirely possible I'm missing something). After reading > the J2SE docs for PooledConnection it seems like > PooledConnection.getConnection() should not return the physical > connection but a handle that when closed indicates the connection > should be returned to the pool. If that is the case the tomcat jdbc > pooling library handling the call incorrectly and its a bug. > > I wanted to ask to post here before submitting a bug to the tracker in > case I'm missing something. > > Thanks, > Jonathan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
