You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by ITAGAKI Takahiro <it...@oss.ntt.co.jp> on 2007/10/24 08:33:48 UTC

Problem on DBCP with exhausted pool

Hello,

I found DBCP does not work well when the connection pool is exhausted:

  1. There are many context switches in the server.
  2. Client-to-client response times are not stable.

If the issues are fiexed, we can use DBCP as a better connection multiplexer
(i.e, server threads > max database connections).

As far as I can see, their cause is same; the combination of wait() and
notifyAll() is used for the thread management in pool.impl.GenericObjectPool.
When the connection pool is exhausted and a connection is freed, all of
waiters are waken up. One of the threads will win the race, and other threads
will sleep again. It's the reason of 1. At the same time, we cannot control
the order of threads acquiring the free connection. FIFO ordering is needed
to tackle with 2.

Is it possible to replace wait-and-notifyAll to waking-up one-by-one
and FIFO ordering? For example, to use ReentrantLock(fair=true).
If I'll try to fix the issues, which class should I change?
I only need the connection pool used in DBCP, but GenericObjectPool
might affect other modules.

Comments and advices welcome.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Re: Problem on DBCP with exhausted pool

Posted by "Wm.A.Stafford" <st...@marine.rutgers.edu>.
I would like to add something to this request.  I have spend a two 
frustrating weeks trying to figure out what was happening with our 
application only to eventually discover what Itagaki described .  I 
think the JavaDocs for BasicDataSource at least and probably anything 
that might use the pooling support should mention something about the 
behavior when the pool is  exhausted.  Specifically a description of 
the  situation, what the symptoms of pool exhaustion problems are and 
what some possible solutions might be.  Also, the JavaDoc for 
BasicDataSource in dbcp-1.2.2 has virtually nothing about abandoned 
connections. I think some discussion of the situation and how dbcp  
deals with it might help users of dbcp or BasicDataSource quickly figure 
out what is going wrong when they see usual behavior. 

 I would be glad to write this JavaDoc, just let me know.

-=bill stafford

ITAGAKI Takahiro wrote:
> Hello,
>
> I found DBCP does not work well when the connection pool is exhausted:
>
>   1. There are many context switches in the server.
>   2. Client-to-client response times are not stable.
>
> If the issues are fiexed, we can use DBCP as a better connection multiplexer
> (i.e, server threads > max database connections).
>
> As far as I can see, their cause is same; the combination of wait() and
> notifyAll() is used for the thread management in pool.impl.GenericObjectPool.
> When the connection pool is exhausted and a connection is freed, all of
> waiters are waken up. One of the threads will win the race, and other threads
> will sleep again. It's the reason of 1. At the same time, we cannot control
> the order of threads acquiring the free connection. FIFO ordering is needed
> to tackle with 2.
>
> Is it possible to replace wait-and-notifyAll to waking-up one-by-one
> and FIFO ordering? For example, to use ReentrantLock(fair=true).
> If I'll try to fix the issues, which class should I change?
> I only need the connection pool used in DBCP, but GenericObjectPool
> might affect other modules.
>
> Comments and advices welcome.
>
> Regards,
> ---
> ITAGAKI Takahiro
> NTT Open Source Software Center
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org