[pool] Queue-, SoftReference-based object pool

[Javier Kohen <jk...@users.sourceforge.net>]

Hi,

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.

Greetings,
-- 
Javier Kohen <jk...@users.sourceforge.net>
ICQ: blashyrkh #2361802
Jabber: jkohen@jabber.org

Re: [pool] Queue-, SoftReference-based object pool

[Javier Kohen <jk...@users.sourceforge.net>]

Sandy,

El mié, 15-02-2006 a las 22:20 -0500, Sandy McArthur escribió:
> 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.

My implementation can be trivially adapted to use the
java.util.concurrent backport project. I sure hope we see Pool 1.3 soon,
as version 1.2 doesn't even compile with the default compiler options in
Java 5 :)

> 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.

Thanks for offering your implementation, but it does far more than I
need, which is simply a simple, lock-free (or at least cheap)
implementation. I don't see the need for the configuration power your
project offers, but good luck with it.

Reply-to: jkohen@users.sourceforge.net, please. I'm getting off the list
(I set the header myself, but I'm afraid the list manager will override
it).

Thanks,
-- 
Javier Kohen <jk...@users.sourceforge.net>
ICQ: blashyrkh #2361802
Jabber: jkohen@jabber.org

Re: [pool] Queue-, SoftReference-based object pool

[Sandy McArthur <sa...@gmail.com>]

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 <jk...@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