Commons Dbcp
  1. Commons Dbcp
  2. DBCP-373

Ability to configure upper bound on total number of connections managed by pooled data sources across all keys (user/password).

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.4
    • Fix Version/s: 2.0
    • Labels:
      None

      Description

      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.

        Activity

        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        795d 14h 35m 1 Mark Thomas 13/Feb/14 21:55
        Resolved Resolved Closed Closed
        106d 6h 12m 1 Phil Steitz 31/May/14 05:08
        Phil Steitz made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Mark Thomas made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        Mark Thomas added a comment -

        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.

        Show
        Mark Thomas added a comment - 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.
        Phil Steitz made changes -
        Field Original Value New Value
        Fix Version/s 2.0 [ 12313721 ]
        Scott Cameron created issue -

          People

          • Assignee:
            Unassigned
            Reporter:
            Scott Cameron
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development