tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Fleischhans <>
Subject Re: JDBC connection pooling problem
Date Tue, 02 May 2006 12:15:44 GMT
You're absolutelly right Marc,
but the connection is being described by the connection context  
containing the username and the password. Each application has its own  
DB account, so as you have written bellow, the application gives the  
connection back to the pool BUT only the same application can reuse it  
again, becouse the other ones use different accounts, so different  
connection contexts

   Quoting Marc Farrow <>:

> This sounds like poor coding to me.  Your application should get
> connection object from the pool and immediately release when
done.  Having
> an application hold onto a connection (especially in client/server)
world is
> bound to cause you to run out of connections or reach timeouts.
> On 5/2/06, Michal Fleischhans <> wrote:
>> Hi all,
>> I have a problem with connection pooling.
>> Example:
>> - about 30 applications using the pool
>> - each application uses 1 DB username/password (30 users)
>> imagine following situation:
>> Only 1 application works hard, the others do nothing. This
>> takes for example 80% of all possible connections to the DB, store
>> them in a pool and reuses them too often. The other 29
>> become fully loaded BUT they have only 20% of resources (possible
>> connections) together, becouse the first application still holds
>> reuses the 80% of connections. Is there any way how to manage this
>> problem, so that all applications have the same amount of
>> when they all are fully loaded ? To tell JDBC pool that every DB
>> (application) can use only 1/30 of possible connections doesn't
>> resolve the problem, because when only one application is working,
>> it's using only 1/30 of possible connections even if the other
>> are free to use.
>> thanks in advance
>> Michal, Bno - Czech Republic
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> --
> Marc Farrow

Michal Fleischhans

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

View raw message