commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Thomas (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (DBCP-373) Ability to configure upper bound on total number of connections managed by pooled data sources across all keys (user/password).
Date Thu, 13 Feb 2014 21:56:19 GMT

     [ 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/user@commons.apache.org/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)

Mime
View raw message