[
https://issues.apache.org/jira/browse/DBCP-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DBCP-373.
------------------------------
Resolution: Fixed
It is always the simple looking requests that end up requiring far more effort
to implement that you expect.
I have been through SharedPoolDataSource and PerUserPoolDataSource and exposed
all of the configuration properties for the underlying connection pools. Note
that there is no simple way to provide an upper limit for the total connections
when using PerUserPoolDataSource - that is (one of) the fundamental difference
between the two approaches.
> Ability to configure upper bound on total number of connections managed by
> pooled data sources across all keys (user/password).
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: DBCP-373
> URL: https://issues.apache.org/jira/browse/DBCP-373
> Project: Commons Dbcp
> Issue Type: Improvement
> Affects Versions: 1.4
> Reporter: Scott Cameron
> Fix For: 2.0
>
>
> For a discussion about this request, please refer to:
> http://www.mail-archive.com/[email protected]/msg07215.html.
> In general, it feels like SharedPoolDataSource and PerUserPoolDataSource
> could be made much more powerful and flexible by exposing as much of the
> configurability of the underlying ObjectPool as possible. It seems to me
> that if consumers are going to want to customize behavior it is very likely
> that it is the ObjectPool that they will want to tweak. Exposing the power
> of the inner pool would be really useful.
> But if that doesn't make sense, at least allowing a global cap on the total
> number of connections across all keys in the pool data source would solve at
> least the problem I describe in the mailing list post.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
