Okay, I think I now have an idea of what you are trying to achieve. In
terms of Pool you would want a pool with a maxActive setting set to 4
and make sure there is no minIdle or idle object evictor or anything
else that could cause the pool to loose poolable objects.
Correct. Only I think it is a bit unstable to have a factory producing
max 4 poolable objects and as an absolute requirement have the
associated pool handling set to maxActive = 4. If either one gets
changed the solution goes AWAL (meaning CPU 100%).
So in order to maximize user experience, the alternative pool
implementations have three constructors: one empty, one with a factory
and one with a collection, for example:
StackObjectPool lPool = new StackObjectPool( myList );
StackObjectPool lPool = new StackObjectPool( new
JdbcConnectionFactory(...) );
RoundRobinObjectPool lPool = new RoundRobinObjectPool( myList );
RoundRobinObjectPool lPool = new RoundRobinObjectPool( new
JdbcConnectionFactory(...) );
With this approach I have a clear separation between things-to-be-pooled
and how-the-pool-behaves, and can mix and match them.
Pool assumes that poolable objects could become invalid over time. If
makeObject cannot create objects as needed, the the pool would run
dry.
That is a good assumption: all poolable objects should go through the
activate/validate/passivate life cycle.
If you want to share those implementations, create an issue and attach
the sources. I cannot promise it will be included in the official
package but we can point others there if they have similar needs.
I want to add a PriorityObjectPool before that. Since I've been using
Apache's implementation for years I feel I should be contributing back.
And it's quite simple to do, below is the round robin implementation:
protected List iListOfPooledObjects = new ArrayList();
protected Object obtainPooledObject()
{
return iListOfPooledObjects.remove(0); // fetch from beginning
}
protected void returnPooledObject(Object o)
{
iListOfPooledObjects.add(o); // return at end
}
All handling is moved out to the abstract parent class, so the code
above really is all there is to it. The stack implementation looks like
this:
protected Stack iListOfPooledObjects = new Stack();
protected Object obtainPooledObject()
{
return iListOfPooledObjects.pop();
}
protected void returnPooledObject(Object o)
{
iListOfPooledObjects.push(o);
}
And similarly the priority pool will use a sorted collection with a
comparator.
It's non-trivial to accept code that wasn't written by Apache members
because of licensing issues but I'm happy to look and learn from a
good idea when I see one.
Interesting. I didn't know that. I'll put it up once I add the priority
pool. An issue you mean a "bug" report in the commons area?
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
