Commons Dbcp
  1. Commons Dbcp
  2. DBCP-368

determine which connections to hold in pool by relative value

    Details

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

      Description

      Situation: a Firebird-Classic database (each connection has independent metadata cache), in a metadata-heavy environment; many "quick" actions will never force the database server to load full metadata, but a few will, in our case resulting in 200MB of metadata cache in memory (takes about 3 seconds to load, visible latency to the user); any connection that has done this is "more valuable" to us, and we'd prefer to keep those connections in the pool, and remove idle connections which haven't incurred this cost yet and are relatively cheap to recreate later if our load increases. Doing this is preferable to forcing ALL connections to load metadata at start, as this means the pool will always have a startup cost (in time), and the server will likely use more memory than really necessary.
      Proposal: add new configuration parameter; if set, run the SQL string and get back a single-column, single-row result-set containing an arbitrary "value" as determined by the connection; prefer to close the lowest-value connections first, to get down to the configured minIdle. Would require querying each open connection, when the pool is over-full, to determine which ones are most valuable. If not set, use current algorithm (based on age?).

        Issue Links

          Activity

          Philip Williams created issue -
          Phil Steitz made changes -
          Field Original Value New Value
          Fix Version/s 2.0 [ 12313721 ]
          Mark Thomas made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Mark Thomas made changes -
          Link This issue is duplicated by DBCP-210 [ DBCP-210 ]
          Phil Steitz made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              Unassigned
              Reporter:
              Philip Williams
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development