commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [pool] Pool config vs. factory hierarchies.
Date Wed, 03 Nov 2010 01:59:32 GMT
On 11/2/10 10:05 AM, Steven Siebert wrote:
> Hey all,
> Sorry I've been away from the discussion, I was stuck in a building with no
> windows for the last week (quite literally) and had very little time to
> breath.  At ApacheCon now, so have a bit of time to hack.
> I caught up on the messages, and I agree with Gary as well.  What can I do
> to help at this point?  I think the group decided to implement immutable
> configuration classes...the pools would provide a reference in the
> pools/factories and sync/reconfigure with the reconfigure()?  Is this right?

I think the config classes either need to be mutable (as they are 
now in trunk for GOP) so the individual properties remain 
*individually* mutable or - my preference - they are immutable and 
used only by the ctors and they are not used to proxy changes to the 
pool properties.

>   One consideration with this is mutability of JMX, each individual change
> though this interface would call reconfigure().

-1 for forcing that.

   Now, I don't think there
> would be frequent, sweeping, this probably won't be a huge
> issue.  If we're going this route, JMX is a non-issue with this (just
> confirming this).  Each pool would implement a MBean that would "expose" the
> configuration settings as well as the pool-specific values (numWaiting, etc)
> for read-only.  If this is good with the group, I look forward to
> helping/completing this so I can finalize a patch for the JMX =)

+1 for MBean exposing properties.  See my last post on what 
properties should be mutable.

> S
> On Tue, Nov 2, 2010 at 3:33 AM, Simone Tripodi<>wrote:
>> Hi all, Phil,
>> thanks for the explanations, very appreciated, I join Gary on saying
>> that maybe my thoughts on Pool are based on incorrect assumptions.
>> Assembling thought from various email and this thread IMHO starts
>> being a little difficult, If we could resume all that thoughts in a
>> wiki page I can take care on refactoring the code to see the design in
>> action.
>> WDYT?
>> Have a nice day,
>> Simo
>> On Mon, Nov 1, 2010 at 3:07 AM, Phil Steitz<>  wrote:
>>> On 10/31/10 9:47 PM, Mark Thomas wrote:
>>>> On 31/10/2010 21:36, Phil Steitz wrote:
>>>>> A radical idea that I have been considering is to propose that we
>>>>> dispense with keyed pools altogether.  The DBCP need can be met without
>>>>> them (see jdbc-pool)
>>>> Can it? I know there are some things that DBCP can do that jdbc-pool
>>>> can't such as
>>>> I thought keyed pools were required for that but I haven't given it much
>>>> more than about 10s thought so I could be wrong.
>>> For SharedPoolDataSource the way it is currently implemented, yes; but
>>> similar to the statement cache, that class does not use anywhere near the
>>> full features of GKOP. It does not allow you to provide a pre-configure
>>> or support cross-pool maintenance. The only thing it really needs is
>>> maxTotal enforcement and a map of GOPs.  I guess having GKOP means you
>> could
>>> make SPDS more full-featured, but I wonder if its not overkill.
>>> Probably best to keep it around if we can find a simple performant way to
>>> maintain it.
>>> Phil
>>>> Mark
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

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

View raw message