> On the KeyedObjectPool interface, does the contract specify
> that there is one and only one instance of the underlying
> object for each name, or is it legitimate for an implementation
> to provide more than one if it wants to (which would essentially
> imply a pool of subpools)?
There can be multiple instances of the keyed pool objects. In fact, both of
the implementations in o.a.c.pool.impl do it that way.
The one-and-only-one approach (which is essentially a self-populating Map,
of course) would be pretty useful for things like PreparedStatements, where
there is little chance of using the same statement on the same connection
simultaneously.
> Whichever way this is decided, it should be made explicit in the Javadocs.
Good point. I'll spell it out. Actually, I thought I mentioned the "pool
of subpools" notion pretty directly, but I don't see it now so I must have
dropped it.
> One thing I will want to implement myself here in the near term is
> a pool implementation based on a linked list rather than a stack.
> There are some scenarios (DBCPs, pools representing
> "load balanced" resource access, etc.) where you will want to
> spread the object usage across all of the objects you have
> created, rather than concentrating on those at the top of
> the stack. Looking at the APIs, this should fit in pretty nicely.
Great. I can think of a couple of uses for that as well.
