commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom <>
Subject Re: [POOL] a conceptual implementation error?
Date Tue, 21 Nov 2006 20:05:25 GMT

> 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 

    protected Stack iListOfPooledObjects = new Stack();
    protected Object obtainPooledObject()
        return iListOfPooledObjects.pop();
    protected void returnPooledObject(Object o)

And similarly the priority pool will use a sorted collection with a 

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


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

View raw message