On Wed, Dec 7, 2011 at 9:27 AM, Cameron, Scott <scott.came...@sap.com> 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.

Phil
>
> Thanks in advance!
>
> scott

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

Reply via email to