commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandy McArthur <sandy...@gmail.com>
Subject Pool: comments requested for a new implementation
Date Wed, 09 Nov 2005 06:17:14 GMT
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:
http://sandy.mcarthur.org/pool/

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message