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.
