[pool] GKOP clearOldest behavior

[Phil Steitz <ph...@gmail.com>]

I notice now that in the doco cleanup before pool 1.5, we left one more
inscrutable "feature" of GKOP undocumented, namely the behavior determined
by the clearOldest method added in pool 1.3.   This (non-optional) feature
destroys 15% of the "oldest" idle instances in the union of the pools to
"make room" when a borrowObject attempt bumps up against maxTotal and there
are idle instances (with other keys) that could be sacrificed.  This
behavior makes sense for the DBCP use case (prepared statement pools), but
may not always be desirable.  I think it should be configurable (whether or
not to do it and possibly the trimming %) and documented.   The 1.5 changes
to take factory methods out of synch blocks also increase the activation
rate of clearOldest, since the internal processing count is included in the
guard.  It might actually be better to eliminate that from a performance
perspective (i.e. only activate when _totalActive + _totalIdle >=
_maxTotal).

This feature was implemented in POOL-49.  Prior versions just invoked
clear() to eliminate all idle instances when maxTotal was attained.

Phil

Re: [pool] GKOP clearOldest behavior

[Simone Tripodi <si...@gmail.com>]

Hi Phil,
+1 for me!
Simo

Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Sat, Dec 25, 2010 at 5:44 PM, Phil Steitz <ph...@gmail.com> wrote:
> I notice now that in the doco cleanup before pool 1.5, we left one more
> inscrutable "feature" of GKOP undocumented, namely the behavior determined
> by the clearOldest method added in pool 1.3.   This (non-optional) feature
> destroys 15% of the "oldest" idle instances in the union of the pools to
> "make room" when a borrowObject attempt bumps up against maxTotal and there
> are idle instances (with other keys) that could be sacrificed.  This
> behavior makes sense for the DBCP use case (prepared statement pools), but
> may not always be desirable.  I think it should be configurable (whether or
> not to do it and possibly the trimming %) and documented.   The 1.5 changes
> to take factory methods out of synch blocks also increase the activation
> rate of clearOldest, since the internal processing count is included in the
> guard.  It might actually be better to eliminate that from a performance
> perspective (i.e. only activate when _totalActive + _totalIdle >=
> _maxTotal).
>
> This feature was implemented in POOL-49.  Prior versions just invoked
> clear() to eliminate all idle instances when maxTotal was attained.
>
> Phil
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org