2010/10/17 Phil Steitz
> On 10/17/10 8:53 AM, Benoit Perroud wrote:
>
>> Making pool be able to be resized at runtime will introduce extra
>> complexity, that could be otherwise totally delegated to a BlockingQueue
>> as
>> backend structure.
>>
>
> I do
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
Making pool be able to be resized at runtime will introduce extra
complexity, that could be otherwise totally delegated to a BlockingQueue as
backend structure.
Moreover is there some ideas of what kind of implementation will be used to
implement the pool v2 ?
ArrayBlockingQueue is IMO a good can
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
Dear all,
Regarding
1) Replace wait/notify with 1.5+ thread management
Is there already any work or ideas on how to use Java util concurrent (JUC)
?
I did some tests with BlockingDeque as objects repository (Deque instead of
Queue to be able to achieve FIFO or LIFO behavior) and AtomicInteger a
