Druid 查詢超時配置的探究 → DataSource 和 JdbcTemplate 的 queryTimeout 到底誰生效？

• 2022 年 7 月 25 日
• 筆記
• druid, 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 配置項生效的過程還有其他配置項參與了邏輯，而非簡單的直接賦值，大家可以琢磨下為什麼這麼實現