commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wm.A.Stafford" <>
Subject Re: DBCP deadlock
Date Thu, 12 Nov 2009 19:32:18 GMT
I used the following to track down a connection leak when using an older 
version of DBCP.  I have not used it with later versions but I believe 
some of the DBCP methods seen here have been removed.  This method was 
called after each call to open() and we saw the number of active 
connections just keep on growing.

    public static String getConnectionPoolInfo( Dao dao){
        BasicDataSource ds = dao.getDataSource() ;
        String configInfo = "initialSize=" + ds.getInitialSize() + " 
maxActive=" + ds.getMaxActive() + " maxIdle=" + ds.getMaxIdle() + " 
minIdle=" + ds.getMinIdle() ;
        return  configInfo + "\nactive connections=" + ds.getNumActive() 
+ " idle connections=" + ds.getNumIdle() ;

hope this helps,

Marc Logemann wrote:
>>> But in my view, connection leak means, i am not closing SQL connections
>>> (apart form the fact that i checked this) but then these connections
>>> would be "in use" by the pool and also "in use" by the the server jobs
>>> that hold the connections. But thats not the case.
>> The "server jobs" may have vanished entirely, resulting in the
>> connection wrappers that they checked out from the pool getting
>> *abandoned*. Unless and until these objects are returned to the pool
>> by executing close() on them, DBCP considers them active, in use. If
>> they are never returned, pool capacity is leaked.
> THen it would be interesseting to know who is killing the server jobs 
> on the i5 (IBM) machine if not the pool itself. I am quite sure that 
> the DB2 on the i5 is not deleting connection jobs because it cant know 
> if they are still needed. If DBCP is killing them it should not think 
> at the same time that they are active and wait for a close() call.
> In my view, a typical connection leak has plenty of connections on the 
> DB side (and in the pool of course) which are open and which never get 
> closed. This is a typical situation.
> I will replace DBCP with the other mentioned pool if pool1.4 doesnt 
> solve it and if i really have a problem with closing connections and 
> thus leaking, i would face the same problems with C3P0 too.
> BTW is there a log level which i can use where DBCP prints out how 
> many connections he thinks are currently in use by the pool? I mean, 
> this would be a valuable information for debugging.
> Marc
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message