commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simone.trip...@gmail.com>
Subject Re: [pool] Pool config vs. factory hierarchies.
Date Tue, 02 Nov 2010 07:33:25 GMT
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


Mime
View raw message