commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <>
Subject RE: Pool: comments requested for a new implementation
Date Wed, 09 Nov 2005 13:57:11 GMT
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! :-)

-----Original Message-----
From: Sandy McArthur [] 
Sent: Wednesday, November 09, 2005 1:17 AM
To: Jakarta Commons Developers List
Subject: Pool: comments requested for a new implementation

In the past weeks I've been working on a new implementation for Pool
that I'm calling a Composite Object Pool (COP). I'm at the point where
I think I've implemented everything I think the pool should have and
then some. I would like feedback on the code and if the response is
favorable I'll submit it for addition to the pool project.

Generated JavaDocs and source code can be found at:

Below is a list of things going for this code:

* Implements almost all existing features in the current
implementations. I think the ability to specific a minIdle object
count and to skip validation when borrowing objects are the only
existing features not implemented. I think it's wrong to not implement
the former and I'm not convinced the ladder is really a good thing.

* Very consistent features/behavior across pool types. The feature set
of GenericObjectPool (COP) is quite different than StackObjectPool
(SOP). With COP the features available to a LIFO (SOP) are the same as
the features available to a FIFO (GOP)

* Only returns an activated and valid object or a newly created
object. It seems silly to me to require clients of an ObjectPool to
deal with checking and validating borrowed objects.

* Pools are named by what they do, not how they are implemented. eg:
LifoOP vs StackOP

* Active objects that are not returned to the pool can be detected.
Optionally, the stack at time of borrow for lost objects can be logged
to aid in debugging. I think this feature is pretty cool.

* Synchronization is maintained via a private lock idiom.

* Keyed pools have fine grained locking when possible.

* Very modular code. A pool's feature set is assembled with composition.

* All CompositeObjectPools share the same java util Timer thread.

* Idle object evictor turns itself off when the pool is empty to
reduce useless work.

* Idle object evictor will try to limit how long it keeps the pool
tied up during evictions. This is similar to
GOP.setNumTestsPerEvictionRun(int) but time based instead of object
count based.

* The pool factory minimally tries to optimize the the composed object
pool based on parameter values.

* Future proof. (soon to be famous last words?) None of the
implementation is made visible and could be gutted and replaced
without breaking 3rd party code.

* Keyed pools can use a non-keyed PoolableObjectFactory too.

* No decencies beyond the Java 1.4 JDK. It wouldn't be hard to make it
Java 1.3 compatable.

Things left to do are:

* Fix any JavaDoc mistakes.

* Implement more unit tests and fix any bugs that turn up.
(denotations welcome.)

* Current idle object evictor code behaves in a way similar to the
GOP's evictor code. For this to be thread-safe all other access to the
pool while evicting idle objects must be blocked and it is not very
deterministic for when an idle object will actually be evicted.

* Create/Run some benchmarks to verify the performance is good.

* When Java 1.5 is considered a reasonable requirement the
util.concurrent can probably be used to improve parallelization.

Sandy McArthur

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message