commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Perroud <killerwh...@gmail.com>
Subject Re: [pool] introducing Enumerations
Date Sun, 17 Oct 2010 12:37:25 GMT
I would like to take the opportunity of this discussion around the action
when the pool is exhausted to call for background reflexion about this 3
behaviors :

Is there really 3 behaviors ?

For me GROW is useless, because in both case FAIL or BLOCK, the pool will
GROW from initial size to the MAX size.

I find dangerous to let the pool grow until it throws an OutOfMem.

GROW can easily be "emulated" by a big MAX size (like Integer.MAX_VALUE) and
a FAIL behavior once the max is reached.

Kind regards,

Benoit.



2010/10/12 Phil Steitz <phil.steitz@gmail.com>

> On 10/12/10 7:23 AM, Mark Thomas wrote:
>
>> On 12/10/2010 10:32, Simone Tripodi wrote:
>>
>>> Hi all,
>>> following Phil's suggestion to point out candidates for deprecation /
>>> removal, I notice that both GenericObjectPool and
>>> GenericObjectPoolFactory share WHEN_EXHAUSTED_* properties of type
>>> byte to discriminate the action to perform when the pool is exhausted.
>>> Do you agree on replacing byte with enums? I mean, in therms of
>>> design, IMHO is much more elegant having something like:
>>>
>>>     enum WHEN_EXHAUSTED_ACTION = { BLOCK, FAIL, GROW };
>>>
>>> and at the same time provides to end users more clear API.
>>> WDYT? just let me know, have a nice day,
>>>
>>
>> +1.
>>
>> In general, I am in favour of taking advantage of any and all Java 1.5
>> features that lead to cleaner, safer, more readable code. I'm also in
>> favour of removing as much unnecessary, unused, deprecated etc code as
>> possible.
>>
>>  +1 here too.
>
> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message