[
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)
