OK, we've opened a DBCP JIRA issue : https://issues.apache.org/jira/browse/DBCP-269.
It would be very nice to include this patch in OpenEJB 3.0.1. -JF David Blevins wrote: > > > On Jun 11, 2008, at 4:44 AM, jfjames wrote: > >> >> 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 ... > > Great work! Going to be a fantastic contribution. > > Once you're confident on the impact to the dbcp unit tests, craft up a > patch file and open up a JIRA for the issue at > http://issues.apache.org/jira/browse/DBCP > I can help you with instructions on creating patches if you need it > (just an "svn diff > myPatch.txt" for the most part). Then I can go > tap those guys on the shoulder and let em know we're waiting on it and > it's critical for us. > > If we can get them to commit it we won't need to wait for a DBCP > release and can just roll up a custom build that we can use in 3.0.1. > > -David > > >> 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. >> >> > > > -- View this message in context: http://www.nabble.com/DataSource-configuration-for-production-tp17695975p17796021.html Sent from the OpenEJB User mailing list archive at Nabble.com.
