> Using class.forName/newInstance is the one I like the least.
I don't think anyone is suggesting that.
> A factory is fine ( but I don't think of a pool as a factory - or a facade
to a
> factory, there are different patterns, a cache shouldn't create objects ).
I agree, and that's why a factory is an option, but not a requirement, for
the Commons-Pool proposal.
> My preference is the Listener/Event, but that may have an extra overhead
> and be more complex ( but it allow other objects to monitor the pool ).
I think that's conflating two use cases (creating/destroying objects and
being notified when objects are created/destroyed). The Commons-Pool
proposal certainly supports (but doesn't require) the first one, and
implicitly supports the second. Making that implicit support explicit is an
excellent idea.
> But my argument is that we shouldn't impose ( as a "standard" for pools )
> one solution or another or try to create a pool that does all.
> Sometimes "simpler" is better.
I couldn't agree more. So here's one simple, and I would argue pretty
generic, pool interface, and a couple of sample implementations. If that
interface doesn't suffice for you, we can extend it or ignore it. But I
really want a *conventional* (not *standard*) interface for pooling, so that
things like the DBCP can use a wide variety of implementations. As the
convention evolves (or a new convention replaces it), so can the clients,
but the more we follow the convention, the better opportunity to share/reuse
implementations.
I really think we're all in agreement here.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 02, 2001 7:18 PM
To: [EMAIL PROTECTED]
Subject: Re: [PROPOSAL/VOTE] Object Pooling Package
On Tue, 3 Apr 2001, Peter Donald wrote:
> Another way to do it which I like a little more as it is easier on user of
> pool is the following.
>
> final ObjectFactory objectFactory = new SomeObjectFactory();
> final Pool pool = new DefaultPool( ..., objectFactory, ... );
>
> //If pool empty then objectfactory will be called
> Object o = pool.get( )
Yes, I know - or the ( almost equivalent ) PoolListener.poolEmptyEvent()
( and the pool user may add more objects to the pool ).
All are valid solutions - each has advantages and some problems.
Using class.forName/newInstance is the one I like the least. A factory is
fine ( but I don't think of a pool as a factory - or a facade to a
factory, there are different patterns, a cache shouldn't create objects ).
My preference is the Listener/Event, but that may have an extra overhead
and be more complex ( but it allow other objects to monitor the pool ).
But my argument is that we shouldn't impose ( as a "standard" for pools )
one solution or another or try to create a pool that does all. Sometimes
"simpler" is better.
Costin
