commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandy McArthur <sandy...@gmail.com>
Subject Re: [pool] Queue-, SoftReference-based object pool
Date Thu, 16 Feb 2006 03:20:44 GMT
It does make sense to back a FIFO pool with a java.util.Queue but the
Queue is a Java 1.5 feature and it will be a while before Java 1.5 is
a Pool requirement. The current version of Pool requires Java 1.3 and
after one more mostly bug fix release Pool 2.0 will be started which
will using Java 1.4 as a baseline. I don't expect Java 1.5 to be a
requirement until Pool 3.0.

JVM requirements aside, I'm not sure "a Pool based on a Queue with no
internal synchronization" is strong enough to justify adding it to the
project. That said I do have a "competing" pool implementation and may
be biased. :-) One disadvantage of my code is it does more
synchronization than would be needed for when the user wants a pool
that fits your feature set.

I've designed the composite pool implementation so that the user tells
the CompositeObjectPoolFactory what features they want (FIFO/LIFO,
SoftReferences, maxActive or maxIdle, etc) and the pool factory tries
to create the optimally performing implementation of that pool. If you
want to improve upon what I've got so that it can detect when the
syncronization requiremetns are minimial and the factory returns a
pool implementation with those properties then go for it and I'll work
to get it included in a Pool 2.? release.

Until the composite pool implementation is available in the JCPool SVN
repository I'm hosting it at: http://sandy.mcarthur.org/pool/ Feel
free to play around with it, tear it apart, and tell me where it's
broken or how to make it better.

On 2/15/06, Javier Kohen <jkohen@users.sourceforge.net> wrote:
> I implemented an ObjectPool based on the SoftReferenceObjectPool in
> commons pool. My implementation takes a java.util.queue and has no
> internal synchronization, leaving that up to the queue implementation.
> This is useful, for instance, in concurrent applications that share the
> pool among threads, as locking can be costly and cause contention.
>
> The code is available under the same license as the rest of the project
> for anybody who wants it.

--
Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

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


Mime
View raw message