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