Druid 查询超时配置的探究 → DataSource 和 JdbcTemplate 的 queryTimeout 到底谁生效？

Posted 2023-05-07 chuangsi

前情回顾

　　还记得记一次 Druid 超时配置的问题 → 引发对 Druid 时间配置项的探究遗留的问题吗?

　　如果同时设置 DataSource 的 queryTimeout 和 JdbcTemplate 的 queryTimeout ，那么哪个 queryTimeout 生效？

实践出结果

　　想快速知道答案，做法很简单，两个都设置，看生效的是哪个

　　示例代码：druid-timeout

　　我们在原来的基础上改一下：加上这两个配置项，用单线程测试就行了

　　测试方式和之前一样，给 tbl_user 表加写锁

　　我们来看下花费时长

　　结果很明了： JdbcTemplate 的 queryTimeout 生效

源码寻真相

　　想知道为什么，跟源码呗

　　我们重点看

　　通过方法名我们大致能猜到其作用，我们具体看 queryTimeout 相关的内容

　　con.createStatement()

　　大家仔细看，别跟丢了哦

　　可以看到看到此时 stmt.setQueryTimeout(queryTimeout) 设置的是 DataSource 的 queryTimeout ，也就是 7 秒

　　这里有个细节值得大家留意下

　　不是简单的将 DataSource 的 queryTimeout 赋值给 Statement 

　　有兴趣的可以去看看 DataSource 的 transactionQueryTimeout 和 defaultAutoCommit 的相关源码，这里就不跟了

　　applyStatementSettings(stmt)

　　可以看到，又重置成 JdbcTemplate 的 queryTimeout 了

　　至此，相信大家已经明了了

补充留疑问

　　假设配置了 queryTimeout ，思考如下三种情况

　　1、如果配置 transactionQueryTimeout 

　　2、如果配置了 defaultAutoCommit 会出现什么情况

　　3、如果同时配置了 transactionQueryTimeout 和 defaultAutoCommit ，又会出现什么情况

总结

　　关于 queryTimeout ，相信大家已经清楚了（未考虑 transactionQueryTimeout ）

　　从源码可以看出， queryTimeout 配置项生效的过程还有其他配置项参与了逻辑，而非简单的直接赋值，大家可以琢磨下为什么这么实现

https://www.cnblogs.com/youzhibing/p/16514819.html

Druid配置参数详解-maxWait

参考技术A

画外音：目前Druid在开源中国举办的2019年度最受欢迎中国开源软件中排名第7名，支持Druid的朋友可以去投票哇。 2019年度最受欢迎中国开源软件

maxWait ：从连接池中获取连接的最大等待时间，单位ms，默认-1，即会一直等待下去

笔者在使用Druid时都会设置这个参数，这样如果是获取连接超时，更容易从日志中获取调用失败的原因。

如果超时，Druid会抛出以下异常

在DruidDataSource中的getConnectionInternal方法使用到了maxWait

maxWait默认是不超时，即如果连接池没有空闲连接，则会一直等待下去，但是一般的接口都是有超时时间的，如果接口超时，不方便定位出来是获取不到连接导致的，最好设置maxWait，并且小于接口的超时时间。