Steps to reproduce:
- Create a HikariDataSource A with
HikariConfiguration containing a jdbcUrl and a driverClassName (but neither dataSourceClassName, dataSourceJndiName nor dataSource) and a connectionTimeout of 10s.
- Create a HikariDataSource B with a different
jdbcUrl and a timeout of 20s.
Actual result:
Both data sources use a connection timeout of 20s (the last one wins) because Hikari uses the static method java.sql.DriverManager#setLoginTimeout
Expected result:
Both data sources use their own individual connection timeouts.
This probably means having to use some vendor specific properties, but I think it is preferable to the current behavior. Even ignoring the connectionTimeout when no data source is set explicitly would be better than data sources overwriting each others timeouts.
Steps to reproduce:
HikariConfigurationcontaining ajdbcUrland adriverClassName(but neitherdataSourceClassName,dataSourceJndiNamenordataSource) and aconnectionTimeoutof 10s.jdbcUrland a timeout of 20s.Actual result:
Both data sources use a connection timeout of 20s (the last one wins) because Hikari uses the static method
java.sql.DriverManager#setLoginTimeoutExpected result:
Both data sources use their own individual connection timeouts.
This probably means having to use some vendor specific properties, but I think it is preferable to the current behavior. Even ignoring the connectionTimeout when no data source is set explicitly would be better than data sources overwriting each others timeouts.