>From the Javadocs for GenericObjectPool:
"when the pool is exhausted (i.e., the maximum number of active
objects has been reached), the borrowObject() method should simply
create a new object anyway. "
So, it's a different case. It allows for you to disregard the maximum size.
On Sun, Oct 17, 2010 at 8:37 AM, Benoit Perroud <killerwh...@gmail.com> wrote:
> 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.ste...@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-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
