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: comments requested for a new implementation
Date Wed, 09 Nov 2005 18:43:34 GMT
Currently Pool only depends on the CursorableLinkedList when using the
Generic[Keyed]ObjectPool classes. I'd like to see this go away for two
reasons.
First, because the size of the Collections jar (546K) dwarfs the Pool
jar (41K) and it's a slightly more of a hassle to manage two libs vs
one.
Second, because the advantage of a CursorableLinkedList has a
Cursor/ListIterator that allows concurrent modification to the list
while using the cursor. Pool's use of this cursor is synchronized so
that while the cursor is being used no other access to the object pool
is allowed, negating the advantage of the CursorableLinkedList.

On 11/9/05, James Carman <james@carmanconsulting.com> wrote:
> Actually, commons pool already depends upon commons collections, so it's not
> that much of a stretch.

On 11/9/05, James Carman <james@carmanconsulting.com> wrote:
> If you don't mind a dependence upon Commons Collections, you should come up
> with a BufferPool, using the Commons Collections Buffer interface.  The
> Buffer interface allows you to abstract away the LIFO vs. FIFO vs. priority
> queue vs. some other implementation stuff.  All you do is call remove() and
> add().  That way, if you wanted a new type of pool, you just supply a
> different implementation of Buffer.  Just an idea! :-)

--
Sandy McArthur

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