On 11/23/18 2:57 AM, Mark Struberg wrote:
should read: This change (putting a new item back to the idle pool) was needed
to prevent a dead-lock....
*grabbing a fresh coffee* le
I am sorry I did not look carefully enough at this issue before
reviewing the change. After reviewing the DBCP ticket (OP likely
unrelated, IMO), I think that the right answer here is WONT_FIX.
That sounds harsh, but it seems to me that the obvious solution here
is for the user to set maxIdle to at least 1. What the fix does is
effectively that, without changing the setting. If waiting threads
die or time out while the create is happening, there will be an idle
instance in the pool and for certain one is being put there on the
way to getting checked back out. See comments on POOL-327.
If the consensus is to insert this workaround to enable the pool to
retain liveness in the use case, it's probably best to use
ensureIdle(1, false) (see POOL-240). It could be that just moving
the call to ensureIdle inside destroy would be OK. But as stated
above, this breaks the maxIdle contract.
I see that your original report / use case here is from DBCP, Mark.
Was it prepared statements or connections that you were trying to
limit to 0 idle? Is there a reason that just using 1 would not work?
Phil
Am 23.11.2018 um 10:49 schrieb Mark Struberg <strub...@yahoo.de>:
This change (putting a new item back to the idle pool was needed to prevent a
dead-pool
---------------------------------------------------------------------
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
