[DBCP] Getting ready to roll 2.1

[Phil Steitz <ph...@gmail.com>]

I am about ready (at last) to start rolling RCs for DBCP 2.1.  I
just opened an issue [1] that I am on the fence about and would like
feedback on.  I am not sure, actually, that it is an improvement to
force initial requests to queue waiting for the pool to be
pre-filled (what the patch now does).  There is a small chance that
with the current code, a client can get a DS with null logWriter,
but it is immediately set thereafter. I am happy to close [1] as
INVALID if others agree that current behavior is better.

Review and feedback on [2] would also be appreciated.  I did think
about fast-failing passivation / activation instead of validation
there, but ended up sticking with what the contributed patch did. 
The feature might be a little more broadly useful if it did not
require testOnBorrow or testOnReturn to dispose of known bad
connections.

Please also speak up now if there is anything else that needs
attention prior to 2.1.

Phil

[1] https://issues.apache.org/jira/browse/DBCP-432
[2] https://issues.apache.org/jira/browse/DBCP-427




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [DBCP] Getting ready to roll 2.1

[Mark Thomas <ma...@apache.org>]

On 31/01/2015 20:03, Phil Steitz wrote:
> I am about ready (at last) to start rolling RCs for DBCP 2.1.  I
> just opened an issue [1] that I am on the fence about and would like
> feedback on.  I am not sure, actually, that it is an improvement to
> force initial requests to queue waiting for the pool to be
> pre-filled (what the patch now does).  There is a small chance that
> with the current code, a client can get a DS with null logWriter,
> but it is immediately set thereafter. I am happy to close [1] as
> INVALID if others agree that current behavior is better.
> 
> Review and feedback on [2] would also be appreciated.

I skim read the patch. I wonder about the portability / usefulness of
the default values for the disconnection codes but a) I don't have a
better set to suggest right now and b) they are configurable anyway so
no objections from me.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org