> One problem is with the pool acting as factory for the pooled
> objects. It may looks simple ( Class.forName, newInstance) but it's not
> allways simple ( what if you need another class loader ? special
> constructor ? ).
>
> The solution we use ( in tc3 ) is to leave the pool deal with pooling, and
> have the caller deal with creating new objects, i.e.
>
> Pool {
> Object get();
> void put( Object );
> }
>
> User:
>
> Object o=pool.get();
> if( o==null ) {
> // create
> }
> ...
> pool.put(o);
>
You can still do that. You'll note that there is no direct dependency
between the ObjectPool and PoolableObjectFactory interfaces. In fact, the
StackObjectPool implementation (in org.apache.commons.pool.impl) doesn't
require a factory, it can be used just as you describe. (Well,
pool.borrowObject() throws NoSuchElementException rather than returning
null, but it's essentially the same thing.)
> Another solution ( in work right now ) is to use a PoolListener and have
> the caller implement it, and add objects to the pool on
> poolEmpty() events ( and also be notified when objects are removed from
> the pool - very important in some cases ).
Isn't that essentially what PoolableObjectFactory does for you? It's not
"the pool acting as a factory" for instances, the pool *can* have a
*reference* to a factory of instances.
If you want true "listener" functionality (that is, being notified of pool
events but not providing the factory functionality) with the purposed code
base, then you could add it as a PoolableObjectFactory that wraps another
(and broadcasts the create/destroy/activate/passivate events) or as part of
your pool implementation (broadcasting the borrow/return events)
> Another thing I don't like is the interfaces. I think it would be far
> better to just create a component that does pooling - instead of creating
> to define APIs ( as an interface sugests). It's very unlikely other pools
> will implement the same interfaces - we can later define some interfaces
> after we have 2-3 pool implementations and we know what they have in
> common and what's the use pattern, if we really need to.
I don't follow. Every pool is going to have some sort of
giveMeOneOfYourPooledInstances method, and most will have a
imDoneWithThisInstanceYouCanHaveItBackNow method. If we simply agree on
what those methods are called, and have an interface that defines them, then
you and I can share pool implementations quite easily. That's the point,
isn't it?
> Finally, I don't like the fact the lack of notifications - that's related
> with the current design as an abstract interface/implementation instead of
> using the "java bean" pattern ( component / event-listeners ).
Adding event-publication/event-subscription is a good idea. As I mentioned
above, there are a couple of clean places to add this functionality in the
general case, and pool implementations could always define whatever events
they want.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 02, 2001 2:26 PM
To: '[EMAIL PROTECTED]'
Subject: Re: [PROPOSAL/VOTE] Object Pooling Package
Ok, after the +1 on the idea, I have few code comments ( after all that's
the benefit of working with other people - you get feedback that you can
ignore :-).
First, I really don't like mixing the tests with the actual code. I don't
know how difficult it would be to have a sparate directory ( even if it
uses the same package name to access package-protected methods).
One problem is with the pool acting as factory for the pooled
objects. It may looks simple ( Class.forName, newInstance) but it's not
allways simple ( what if you need another class loader ? special
constructor ? ).
The solution we use ( in tc3 ) is to leave the pool deal with pooling, and
have the caller deal with creating new objects, i.e.
Pool {
Object get();
void put( Object );
}
User:
Object o=pool.get();
if( o==null ) {
// create
}
...
pool.put(o);
Another solution ( in work right now ) is to use a PoolListener and have
the caller implement it, and add objects to the pool on
poolEmpty() events ( and also be notified when objects are removed from
the pool - very important in some cases ).
( I'm still working on details - for thread pooling we pre-allocate
objects, so the even will be something like "objectsNeededEvent" ).
Another thing I don't like is the interfaces. I think it would be far
better to just create a component that does pooling - instead of creating
to define APIs ( as an interface sugests). It's very unlikely other pools
will implement the same interfaces - we can later define some interfaces
after we have 2-3 pool implementations and we know what they have in
common and what's the use pattern, if we really need to.
Finally, I don't like the fact the lack of notifications - that's related
with the current design as an abstract interface/implementation instead of
using the "java bean" pattern ( component / event-listeners ).
Of course, it's all a matter of taste - and what matter is the taste of
the user, who can pick the component that he needs.
Costin
On Mon, 2 Apr 2001, Waldhoff, Rodney wrote:
> Here's the proposal for the object pooling package. The attached JAR
> contains the full bundle.
>
> As I mentioned before, I stole the list of initial committers from the
DBCP
> package, since that's the leading client for this package.
>
> - Rod
>
> ---
> Proposal for Pool Package
>
> (0) Rationale
>
> Often a Java application makes use of instances or resources that are
> expensive to create or that need to be limited due to external
constraints.
> Database and other network connections are leading, although certainly not
> the only examples of this situation. A pool of instances can be helpful in
> these circumstances.
>
> A Commons package for object pooling would give committers an opportunity
to
> coordinate their efforts and create and maintain an efficient,
feature-rich
> package under the ASF license.
>
> (1) Scope of the Package
>
> The package will create and maintain an object (instance) pooling package
to
> be distributed under the ASF license.
>
> The package should support a variety of pool implementations, but
encourage
> support of an interface that makes these implementations interchangeable.
>
> (1.5) Interaction With Other Packages
>
> Pool relies upon on standard JDK 1.2 (or later) and the (proposed)
> Commons-Collections APIs for production deployment. It utilizes the JUnit
> unit testing framework for developing and executing unit tests, but this
is
> of interest only to developers of the component. Pool will also be a
> dependency for several future proposed components for the Jakarta Commons
> subproject.
>
> No external configuration files are utilized.
>
> (2) Initial Source of the Package
>
> The initial codebase was contributed by Rodney Waldhoff from a working
> project and can be distributed under the Apache license.
>
> The proposed package name for the new component is
org.apache.commons.pool.
>
> (3) Required Jakarta-Commons Resources
>
> CVS Repository - New directory pool in the jakarta-commons CVS
> repository. All initial committers are already committers on
> jakarta-commons, so no additional
> user setups are required.
> Mailing List - Discussions will take place on the general
> [EMAIL PROTECTED] mailing list. To help list subscribers
> identify messages of interest, it is
> suggested that the message subject of messages about this component
be
> prefixed with [Pool].
> Bugzilla - New component "Pool" under the "Commons" product category,
> with appropriate version identifiers as needed.
> Jyve FAQ - New category "commons-pool" (when available).
>
> (4) Initial Committers
>
> Morgan Delagrange
> Geir Magnusson Jr.
> Craig R. McClanahan
> Rodney Waldhoff
> David Weinrich
>
>
