On 11/10/05, robert burrell donkin <[EMAIL PROTECTED]> wrote:
> thanks to sandy's hard work, looks like pool's starting to gain some
> momentum. this seems like a good time to start a thread about the
> future.
Here is my Pool wish list. Since these could change the behavior of
existing code (but not source code compatability) they should probably
be held off until Pool 2.0:
* Clarify contracts described in the javadocs, specifically:
* I think an [Keyed]ObjectPool.borrowObject should only return an
object that is: 1. newly created via PoolableObjectFactory.makeObject
or 2. previously idle and has passed through
PoolableObjectFactory.activateObject and
PoolableObjectFactory.validatedObject or 3. throw an exception.
* The javadacs for [Keyed]ObjectPool.borrowObject should state by
contract that borrowed objects must be returned to the pool via
returnObject OR invalidateObject. Currently it only lists
returnObject.
* The javadacs for [Keyed]ObjectPool.borrowObject should list
NoSuchElementException as one of the thrown exceptions. Techically a
NSEE is included with "throws Exception" but listing NSEE would help
clients better deal with exceptions. If you are using a pool that
limits the number of active objects then a NSEE isn't that big of a
deal relative to any other exception which would indicate a truely
unexpected problem. Since NoSuchElementException extends
RuntimeException adding this wouldn't break API compatability.
* [Keyed]PoolableObjectFactory in the package description asserts that
activateObject will be invoked on every object returned from the pool.
The method description asserts that activeObject will be used to
"reinitialize an instance to be returned by the pool." What is
ambiguous is if activateObject is used to new created objects from
makeObject.
It's my opinion that activateObject should only be used on existing
objects that are being returned from the internal idle object pool.
This behavior has the advantage that it's possibly more efficient. In
my experience newly made objects are almost always in the same state
that an activated object would be in.
Also, It's my opinion if activateObject throws an exception than that
idle object should be discarded and another should be borrowed from
the pool. If this fails until there are no more idle objects and newly
made object is needed it is much easier to write code that only lets
exceptions from makeObject propagate out ObjectPool.borrowObject.
* [Keyed]PoolableObjectFactory in the package description asserts that
validateObject will only be invoked on an "activated" object. The
method description says that "Ensures that the instance is safe to be
returned by the pool. Returns false if this object should be
destroyed." I pretty much agree with both of those statements.
It's my opinion that validateObject should only be invoked on: 1.
previously idle objects that have been activated and are about to be
borrowed from the pool or 2. optionally by returnObject before
passivateObject is called or 3. by the idle object evictor but not
before the evictor has called activateObject and just before the
evictor then calls passivateObject or destroyObject.
* It's not clearly stated what is supposed to happen to other methods
after close has been called on a pool. The existing code throws an
IllegalStateException when any other method on the pool is invoked.
Personally, I think only borrowObject should throw an
IllegalStateException and other methods such as returnObject or
invalidateObject should just silently fail. My reasoning for this is
say you have a threaded app with a number of currently borrowed
objects. You shut the app down which calls the close method. As it is
now, any worker threads that try to return borrowed objects will
encounter an IllegalStateException. I think less harm would be done if
those methods failed silently.
* The [Keyed]PoolableObjectFactory getNumIdle and getNumActive methods
currently throw an UnsupportedOperationException if they aren't
supported. I kinda think it would be easier on clients if they simply
reuturned a negative value when those operations are not supported. As
it is now if you have code similar to:
if (pool.getNumActive() > 15) { log.message("borrowed more than expected"); }
you really need to wrap it in a try/catch to be safe which I find a
bit silly. Since UnsupportedOperationException is a RuntimeException
removing this doesn't break API compatability.
--
Sandy McArthur
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
