commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
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, changes...so 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.

Phil
>
> S
>
> On Tue, Nov 2, 2010 at 3:33 AM, Simone Tripodi<simone.tripodi@gmail.com>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
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Mon, Nov 1, 2010 at 3:07 AM, Phil Steitz<phil.steitz@gmail.com>  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 https://issues.apache.org/bugzilla/show_bug.cgi?id=49543
>>>>
>>>> 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
>> GKOP
>>> 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: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message