commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <>
Subject Re: [pool] why the composite pool implementation isn't plugable [was: picking descriptive class names]
Date Mon, 27 Mar 2006 07:30:45 GMT
On 3/26/06, Sandy McArthur <> wrote:
> On 3/25/06, Rahul Akolkar <> wrote:
> > On 3/25/06, Sandy McArthur <> wrote:
> > <snip/>
> > > The enums above don't actually specify any implementation, they
> > > describe desired features of a pool. The actual implementation isn't
> > > broken down into four parts like that so try not to confuse how you
> > > would implement that feature with how you would request that feature.
> > >
> > <snap/>
> >
> > Why isn't it broken down like that?
> Because there are fundamentally three parts to a pool's behavior.
> 1. How objects are treated while they are in the idle object pool.
> 2. How objects are added/removed from the idle object pool.
> 3. How objects are treated while they are out of the pool, aka: active.
> I choose to map these three aspects to four types of behavior because
> The composite pool is already plugable, you must give it a
> PoolableObjectFactory. :-)

Isn't the PoolableObjectFactory orthogonal to the four enum types you
mention? Those tune the FactoryConfig?

> Not everything is made better because it's made plugable (or
> I'm not against plugable APIs. They often make sense but not always,
> and this is one time they don't. I also want the composite pool code
> to be "future proof".
> With a fully plugable API the synchronization optimization above
> wouldn't really be available.

No silver bullet, we can only guarantee what is provided out of the
box. All the internal optimizations you list may be appealing, and
what I take from your post is that the optimizations rely on fact that
the four "behavior" impls will always be one of the enum'ed ones. The
question that I still cannot address is -- what is the implication of
needing a enum'ed behavior that is not provided? Maybe that is what
really makes this "future proof". I don't think we know.

> Peter Steijn who emailed a week ago is exploring
> some new ways to improve the performance of Pool (and by extension
> Dbcp) by using some more complex threading behaviors. We've discussed
> some of his ideas off-list and provided his ideas pan out maybe the
> composite pool code in Pool 2.1 will be faster and client code using
> pool won't have to know or care how the improved performance came
> about.

2.1 because we'd rather get 2.0 out first, instead of waiting to try
out the ideas? If you guys think its appropriate, you might even move
that conversation here? Maybe others are interested as well; I am :-)
Plus it will give us better background while reading the commit

> >
> > Since we're talking about Pool 2.0 and beyond, perhaps a focus on
> > similar extensibility is justified, and maybe we should revisit the
> > enumeration approach, even before we get to names.
> If you want to implement a more plugable pool implementation and put
> the plugable pool and composite pool code in a steel cage match to the
> death based on usability, flexibility, and performance I'm all for it.

I think this has value. In terms of a major version release, we might
want to use some of liberties we get the best we can, and to that end,
playing with multiple options can be beneficial. If I can make some
progress on the things that are already on my plate within the next
few months, I'll play in a new branch (and in that case, I'll ping the
list for objections first). However I am hardly talking about a
complete rewrite, so it should have the same usability and performance
(for out-of-the-box impls) since I'll base it off of your
contribution, just to be more flexible on the enums front. Maybe that
puts it in a higher weight class already? ;-)


P.S.- [pool] code is quite hard to read with all that horizontal
scrolling. Irrespective of the code already in place, maybe we should
stick to a reasonable (80?) character line width for new code?

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

View raw message