commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [dbcp] Handling many different user accounts over time
Date Sat, 10 Dec 2011 02:29:59 GMT
On Wed, Dec 7, 2011 at 9:27 AM, Cameron, Scott <> wrote:
> Hi,
> I'm considering using either SharedPoolDataSource or PerUserPoolDataSource to do some
connection pooling but I've noticed that there doesn't seem to be any way to configure an
upper bound on the total number of connections in the pool across all users.
> For example, say I have 5,000 named users in my database.  Any of the 5,000 can come
in to request a DB connection at any time, but likely no more than, say, 100 of them will
ever be active at a particular point in time.  If I want to allow 3 connections per user,
how do I ensure that I'm not eventually going to end up with 15,000 open connection over time.
> It looks like the "maxTotal" setting on the GenericObjectPool (and GenericKeyedObjectPool)
can be used to control this such that when this absolute upper bound is reached on the pool
the least recently used 15% of connections will be recycled.  But neither SharedPoolDataSource
nor PerUserPoolDataSource expose any way to configure maxTotal.
> Is there another recommended way to solve this problem?  What do high-traffic web containers
like Tomcat or JBoss do to deal with this scenario (if they do deal with it)?

Interesting that this has not come up before.  You are right that
PerUserPoolDataSource does not bound the number of pools that can be
created and SharedPoolDataSource does not bound the total combined
size of the keyed pool it maintains.  Please do open a JIRA requesting
the capability.

An ugly but possibly adequate workaround would be to subclass either
one of the datasources above and override getPooledConnectionAndInfo
to enforce a global bound that you maintain in a new instance variable
before calling the superclass method.

Thanks for reporting this.

> Thanks in advance!
> scott

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

View raw message