This behavior can also be achieved using the maxIdle parameter :
maxActive : -1 or Integer.MAX
maxIdle : 200 for example
we can thus borrow more than 200 objects, and the 201st will be discarded
once returned to the pool.
So now again, couldn't we achieve the same behavior with only FAIL and BLO
On Sun, Oct 17, 2010 at 1:20 PM, Phil Steitz wrote:
>
> Yes, but the question is do you really *need* this option, since setting
> maxActive = -1 effectively accomplishes the same thing.
>
Not exactly. The distinction between the two approaches would be more
obvious at return object time. With
On 10/17/10 12:38 PM, James Carman wrote:
On Sun, Oct 17, 2010 at 12:38 PM, James Carman
wrote:
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 any
On Sun, Oct 17, 2010 at 12:38 PM, James Carman
wrote:
> 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.
>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,
On 10/17/10 8:37 AM, Benoit Perroud 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
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
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 discrimina
Hi James,
thanks for the feedback
Guys, please review r1021756, I introduced a WhenExhaustedAction
enumeration that's shared between all
Generic(Keyed)?ObjectPool(Factory)? components.
I also removed the useless
TestGenericObjectPool.testInvalidWhenExhaustedAction() since
WhenExhaustedAction i
+1 to enums
On Tue, Oct 12, 2010 at 7:34 AM, Simone Tripodi
wrote:
> Hi Mark,
> thank a lot for your feedback! I agree with your POV, since we're
> using Java1.5 we should take advantage of the whole provided features
> :)
> Thanks!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www
Hi Mark,
thank a lot for your feedback! I agree with your POV, since we're
using Java1.5 we should take advantage of the whole provided features
:)
Thanks!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Oct 12, 2010 at 1:23 PM, Mark Thomas wrote:
> On 12/10/2010 1
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
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 wi
13 matches
Mail list logo
