前情回顾
还记得记一次 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 标签：queryTimeout,配置,Druid,源码,JdbcTemplate,transactionQueryTimeout,DataSource From： https://www.cnblogs.com/chuangsi/p/17379079.html