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-368) determine which connections to hold in pool by relative value
Date Tue, 04 Feb 2014 19:28:10 GMT

     [ https://issues.apache.org/jira/browse/DBCP-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mark Thomas resolved DBCP-368.
------------------------------

    Resolution: Fixed

It isn't a perfect solution but I have exposed the new evictionPolicyClassName property from
Pool2 to DBCP. I think, with a little careful configuration you'll be able to get close to
what you need.

> determine which connections to hold in pool by relative value
> -------------------------------------------------------------
>
>                 Key: DBCP-368
>                 URL: https://issues.apache.org/jira/browse/DBCP-368
>             Project: Commons Dbcp
>          Issue Type: New Feature
>            Reporter: Philip Williams
>             Fix For: 2.0
>
>
> 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?).



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message