[
https://issues.apache.org/jira/browse/DBCP-600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aryan Ganjoo updated DBCP-600:
------------------------------
Description:
BasicDataSource.setValidationQueryTimeout(Duration.ofMillis(100)) accepts a
positive timeout, but PoolableConnection.validate() converts it with
Duration.getSeconds(), yielding 0. For a configured validation query, the code
skips Statement.setQueryTimeout; without a query, Connection.isValid(0) is
called. In both JDBC paths, the intended bounded validation becomes effectively
unlimited.
Steps to reproduce on current master e334782f3fa3ea182ffd1e055451f92127e765af:
1. Configure a BasicDataSource with testOnBorrow=true and
validationQueryTimeout=Duration.ofMillis(100).
2. Use the existing TesterStatement validation fixture, whose query needs
longer than one second.
3. Call getConnection().
Actual: validation does not time out; the connection is returned because the
positive sub-second duration was truncated to zero.
Expected: convert a positive sub-second duration to JDBC's minimum nonzero
timeout of one second. Zero and negative durations should retain the existing
no-timeout behavior. The no-query Connection.isValid(int) path should likewise
receive 1, not 0.
A focused regression failed against the unmodified base (expected SQLException,
none thrown) and passed with the patch. The focused
BasicDataSource/PoolableConnection tests, full mvn verify, and default mvn
build passed locally. The fix is submitted as
https://github.com/apache/commons-dbcp/pull/548; hosted checks and maintainer
review are pending.
DBCP-597 concerns validation-query timeout propagation in SharedPoolDataSource
and is distinct from this core PoolableConnection conversion path.
was:
BasicDataSource.setValidationQueryTimeout(Duration.ofMillis(100)) accepts a
positive timeout, but PoolableConnection.validate() converts it with
Duration.getSeconds(), yielding 0. For a configured validation query, the code
skips Statement.setQueryTimeout; without a query, Connection.isValid(0) is
called. In both JDBC paths, the intended bounded validation becomes effectively
unlimited.
Steps to reproduce on current master e334782f3fa3ea182ffd1e055451f92127e765af:
1. Configure a BasicDataSource with testOnBorrow=true and
validationQueryTimeout=Duration.ofMillis(100).
2. Use the existing TesterStatement validation fixture, whose query needs
longer than one second.
3. Call getConnection().
Actual: validation does not time out; the connection is returned because the
positive sub-second duration was truncated to zero.
Expected: convert a positive sub-second duration to JDBC's minimum nonzero
timeout of one second. Zero and negative durations should retain the existing
no-timeout behavior. The no-query Connection.isValid(int) path should likewise
receive 1, not 0.
A focused regression failed against the unmodified base (expected SQLException,
none thrown) and passed with a local candidate. The focused
BasicDataSource/PoolableConnection tests and full mvn verify also passed with
that candidate. No pull request has been opened yet.
DBCP-597 concerns validation-query timeout propagation in SharedPoolDataSource
and is distinct from this core PoolableConnection conversion path.
> Positive sub-second validation timeout becomes unlimited
> --------------------------------------------------------
>
> Key: DBCP-600
> URL: https://issues.apache.org/jira/browse/DBCP-600
> Project: Commons DBCP
> Issue Type: Bug
> Reporter: Aryan Ganjoo
> Priority: Major
>
> BasicDataSource.setValidationQueryTimeout(Duration.ofMillis(100)) accepts a
> positive timeout, but PoolableConnection.validate() converts it with
> Duration.getSeconds(), yielding 0. For a configured validation query, the
> code skips Statement.setQueryTimeout; without a query, Connection.isValid(0)
> is called. In both JDBC paths, the intended bounded validation becomes
> effectively unlimited.
> Steps to reproduce on current master e334782f3fa3ea182ffd1e055451f92127e765af:
> 1. Configure a BasicDataSource with testOnBorrow=true and
> validationQueryTimeout=Duration.ofMillis(100).
> 2. Use the existing TesterStatement validation fixture, whose query needs
> longer than one second.
> 3. Call getConnection().
> Actual: validation does not time out; the connection is returned because the
> positive sub-second duration was truncated to zero.
> Expected: convert a positive sub-second duration to JDBC's minimum nonzero
> timeout of one second. Zero and negative durations should retain the existing
> no-timeout behavior. The no-query Connection.isValid(int) path should
> likewise receive 1, not 0.
> A focused regression failed against the unmodified base (expected
> SQLException, none thrown) and passed with the patch. The focused
> BasicDataSource/PoolableConnection tests, full mvn verify, and default mvn
> build passed locally. The fix is submitted as
> https://github.com/apache/commons-dbcp/pull/548; hosted checks and maintainer
> review are pending.
> DBCP-597 concerns validation-query timeout propagation in
> SharedPoolDataSource and is distinct from this core PoolableConnection
> conversion path.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
