commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wm.A.Stafford" <>
Subject Re: DBCP Locking Up?
Date Tue, 04 Dec 2007 18:55:57 GMT

    We were seeing the same behavior in a lightly loaded application 
when the connection pool was exhausted. I spent several days trying to 
figure out what was happening.  A google search turned up several forum 
and mailing list postings reporting the same problem.  I eventually came 
to the conclusion that the deadlock is some sort of undocumented 
behavior of DBCP that occurs when the pool can no longer fulfill a 
request for a connection.  This was with dbcp-1.2.2 and commons-pool-1.3.  

    I was pretty sure our pool exhaustion was caused by a connection 
leak because we used dbcp to replace a non-pooling DataSource.  So 
connections which would have formerly been garbage collected if not 
closed now were leaked.   We located the leaks by wrapping DBCP with 
class that logged  the state of the pool for every open and close, ex:" active connections=" + pool.getNumActive() + " idle 
connections=" + pool.getNumIdle()) ;

    Eliminating the connection leak eliminated our deadlocks but I never 
figured out what the underlying DBCP problem is. 

    -=bill wrote:
> We are using DBCP with iBatis in a JSF/Ajax webapp running in Tomcat with an Oracle database.
> The application has quite high load and concrrency, and the database is very loaded.
The application is running fine for some days but then freezes at peak hours.
> When I look at a thread dump made while the app hangs, I can see as many threads as we
have connections in the pool (64) in BLOCKED state while calling either borrowObject() or
returnObject(), please see the two examples below. It looks like some kind of deadlock and
the only way out of it seems to be a restart of Tomcat.
> First I thought this is normal with the WHEN_EXHAUSTED_LOCK action, but since we have
maxWait set to 1000 I'd not expect this kind of blocking to happen.
> I tried to reproduce the behavior with a small test app, but here the threads go in TIMED_WAIT
state when the pool is exhausted and become RUNNABLE again as soon as some connection became
available again.
> I really don't understand what is happening and why the pool gets locked up that way.
> Any hint/suggestion welcome!
> Torsten
> "TP-Processor483" daemon prio=10 tid=0x01fe5000 nid=0x11f7 waiting for monitor entry
>    java.lang.Thread.State: BLOCKED (on object monitor)
> 	at org.apache.commons.pool.impl.GenericObjectPool.returnObject(
> 	- waiting to lock <0x9ddf7460> (a org.apache.commons.pool.impl.GenericObjectPool)
> 	at org.apache.commons.dbcp.PoolableConnection.close(
> 	- locked <0xf83f9eb8> (a org.apache.commons.dbcp.PoolableConnection)
> 	at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.close(
> 	at com.ibatis.sqlmap.engine.transaction.jdbc.JdbcTransaction.close(
> 	at com.ibatis.sqlmap.engine.transaction.TransactionManager.end(
> "TP-Processor382" daemon prio=10 tid=0x026f6000 nid=0x25a waiting for monitor entry [0x7de7f000..0x7de81808]
>    java.lang.Thread.State: BLOCKED (on object monitor)
> 	at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(
> 	- waiting to lock <0x9ddf7460> (a org.apache.commons.pool.impl.GenericObjectPool)
> 	at org.apache.commons.dbcp.PoolingDataSource.getConnection(
> 	at org.apache.commons.dbcp.BasicDataSource.getConnection(
> 	at com.ibatis.sqlmap.engine.transaction.jdbc.JdbcTransaction.init(
> 	at com.ibatis.sqlmap.engine.transaction.jdbc.JdbcTransaction.getConnection(
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:



Principal Engineer

The Institute of Marine and Coastal Sciences
Rutgers University
732-932-6555 x367

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

View raw message