本篇文章为你整理了Druid 查询超时配置的探究 → DataSource 和 JdbcTemplate 的 queryTimeout 到底谁生效？（）的详细内容，包含有 Druid 查询超时配置的探究 → DataSource 和 JdbcTemplate 的 queryTimeout 到底谁生效？，希望能帮助你了解 Druid 查询超时配置的探究 → DataSource 和 JdbcTemplate 的 queryTimeout 到底谁生效？。

　　 妈：我想抱小孩，谁乐意抱你呀！

　　 我：刚好小区有人想找月嫂，要不我帮你联系下？

　　 妈：你给我滚

　　 然后她直接把语音给挂了

　　 还记得记一次 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配置项生效的过程还有其他配置项参与了逻辑，而非简单的直接赋值，大家可以琢磨下为什么这么实现

　　以上就是Druid 查询超时配置的探究 → DataSource 和 JdbcTemplate 的 queryTimeout 到底谁生效？（）的详细内容，想要了解更多 Druid 查询超时配置的探究 → DataSource 和 JdbcTemplate 的 queryTimeout 到底谁生效？的内容，请持续关注盛行IT软件开发工作室。

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。