commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandy McArthur <sandy...@gmail.com>
Subject [pool] roadmap 1.3, 2.0, 3.0
Date Wed, 15 Feb 2006 02:47:27 GMT
A lot of this was brought up in Nov 2005 starting with Robert's post:
http://tinyurl.com/aq7cx

Now that all known issues for the existing Pool code have been fixed
I'd like to see one more release of the current code base, probably
dubbed 'Pool 1.3'. I also think this should be announced as the last
version of Pool that will support Java 1.3 JVMs. There really are some
big bugs that were fixed and this should be a drop in replacement for
anyone using the current version pool.

After that I'd like to see the prep towards 'Pool 2.0' started. In
addition to seeing my composite pool implementation added I'd like to
start the process to cleaning up the API as I described back in
November: http://tinyurl.com/76f4n If I recall correctly those changes
don't break API compatibility, only change the behavior to be more
friendly to client code.

The goals of 'Pool 2.0' would be:
* move Java 1.4 as a requirement (eg: the composite implementation
currently uses 1.4 features)
* tighten the behavior of the various implementations (eg: the when
and why of calls to PoolableObjectFactory.makeObject(),
.activateObject(), and .validateObject() aren't consistent.)
* Document the planed changes that will break API implementation
compatibility with the 'Pool 3.0' interfaces. (The changes I want
shouldn't break API compatibility with client code that transitions
from Pool 1.x to 3.0)
* released in the near future

One example of a 2.0 change is changing ObjectPool.getNumActive() to
return a negative value instead throwing  an
UnsupportedOperationException when that method isn't supported by the
pool implementation. (UnsupportedOperationException is a
RuntimeException so removing it from the interface doesn't break the
API)

A change I'd like documented for 2.0 and planed for 3.0 is the more
aggressive changes like making it so ObjectPool interface for the
methods .close(), .clear(), .invalidateObject(), and .returnObject()
don't throw any Exceptions, currently they throw Exception. I think if
there is an Exception, not an Error, they should make a good effort to
clean up, discard the problem object the client is done using, and
fail silently. My thinking is that client code will be more interested
with being done with an object or shutting down than dealing with
problems with the pool.

The goals of 'Pool 3.0' would be:
* implement the more aggressive API changes announced with 2.0.
* require Java 1.5
** use the new util.concurrent for better multi-threaded performance
** consider generic support
** add JMX monitoring
* to be released sometime in 2007, maybe

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