We're back ... It seems we’ve identified the cause of the problem. It is located in DBCP 1.3. In fact, the isClosed method of the DelegatingConnection class doesn’t really close the underlying JDBC connection : * when called from the destroyObject method of the PoolableConnectionFactory, the _closed variable is set to false, * therefore the test if ( _closed || _conn.isClosed() ) doesn’t allow to propagate the close along the delegating chain (up to the JDBC connection).
According to us, it should be replaced by if ( _closed && _conn.isClosed() ). We’ve done some tests with this patch and it works fine : maxActive is never exceeded and the number of connections to the database server is stable. Now, we have to check the impact on the DBCP jUnit tests before going further ... jfjames wrote: > > We've spent some time today investigating what actually happens in the > DataSource ... Not so easy since DBCP code is a little tricky ! > > We've observed that JDBC connections which are realeased from the pool by > the Evictor are not physically closed : > 1/ from the DataSource standpoint : the maximum size of the pool is never > exceeded (numActive is always inferior to maxActive), > 2/ but from the dataserver standpoint : the number of connections is > always increasing (up to the maximum allowed by the server). > > We haven't identified the exact cause of this issue : for some unknown > reason the DelegatingConnection.close() method consider the JDBC > connection as already closed which is wrong. > > Next step tomorrow ... > -- View this message in context: http://www.nabble.com/DataSource-configuration-for-production-tp17695975p17775606.html Sent from the OpenEJB User mailing list archive at Nabble.com.
