Tomcat JDBC連接池：testOnBorrow vs testWhileIdle

Question

由於各種原因，池中的連接可能變為無效：服務器連接超時，網絡問題......

我的理解是Tomcat JDBC連接池不保證它為應用程序提供的連接的有效性。

為了防止（實際上只降低風險）從池中獲得無效連接，解決方案似乎是連接驗證的配置。 驗證連接意味着在數據庫上運行非常基本的查詢（例如SELECT 1;在MySQL上）。

Tomcat JDBC連接池提供了幾個測試連接的選項。 我發現兩個更有趣的是testOnBorrow和testWhileIdle 。

首先，我認為testOnBorrow是最好的選擇，因為它在將連接提供給應用程序之前基本上驗證了連接（具有由validationInterval定義的最大頻率）。

但是經過一秒鍾后我才意識到在使用它之前測試連接可能會影響應用程序的響應能力。 所以我雖然使用testWhileIdle可以更高效，因為它在不使用時測試連接。

無論我選擇哪個選項，它們似乎只會降低獲得無效連接的風險，但這種風險仍然存在。

所以我最后問：我應該使用testOnBorrow還是testWhileIdle或兩者兼而有之？

另外，我很驚訝validationInterval不適用於testOnReturn而且我沒有真正達到testOnConnect的目的。

Answer 1

這沒有100％正確的答案。 這是一個權衡和背景的問題。

大多數情況下， testOnBorrow風險最小，因為它確保（盡可能最好）在從池中返回連接供您使用之前，已經進行了基本的健全性檢查，客戶端和數據庫服務器正在談論條款。
它仍然不能防止服務器連接的競爭狀態下降，在“完整性檢查”和應用程序使用連接的時間之間。
但考慮到這是一個角落案例， testOnBorrow給出了相當不錯的保證。
現在需要權衡的是，每次請求連接時，都會對數據庫服務器進行查詢（無論多么輕量級）。 這可能非常快，但成本仍然不是零。

如果你有一個繁忙的應用程序，具有非常好的數據庫連接可靠性，那么你將從數據開始看到，“對來自池的每個連接請求的有效性檢查”的成本超過檢測連接問題的好處。

另一方面，如果您的應用程序不是一成不變的 （就像大多數真實應用程序一樣），那么擁有testOnBorrow選項是非常有益的。
它確保最大化，您在使用之前有良好的連接。 特別是考慮到失敗的DB操作的“無法輕松恢復”的成本（重試+手動干預+工作流程丟失等）。
現在想象一下，如果你有testOnIdle選項。 這需要您的連接在進行健全性檢查之前空閑（取決於連接的空閑超時）。
這是testOnBorrow的性能改進，但它有其自身的缺點。
- 真實世界的app-to-db-connections不僅僅是基於空閑超時的破壞，它們可以根據防火牆規則，n / w擁塞，db-server-正在進行維護/修補等而被刪除。
- 因此，當您沒有任何類型的“連接驗證”時，它可以追溯到數據中觀察到的連接錯誤數量的數據測量。
使用此選項需要注意的一件事是，當您使用最大連接並且您的應用程序運行良好時，您的池工作效果最佳，並且出於某種原因，如果您的數據庫服務器重啟或同樣如此。 現在所有的實時連接（從客戶端的角度來看）都會出錯，直到空閑超時開始。 所以你的db-issue（這本來就是一場激烈的爭奪）現在有點復雜，直到應用程序連接恢復正常或你重啟應用程序。

最后一個數據點是，對於某些應用程序，關鍵路徑不是“驗證查詢”時間（希望以較低的毫秒數）。 應用程序有更大的問題需要處理。 當然，對於某些應用來說，那個時間非常重要。

Answer 2

只是為了讓您知道，我剛剛對此進行了測試，並且可以同時使用testOnBorrow和testOnIdle屬性。

然而，如上所述，我將選擇testOnBorrow唯一，因為我的應用程序沒有大量流量，並且能夠承擔在連接之前驗證連接。

正如評論中指出的那樣， testOnBorrow不需要驗證查詢。 如果你確實選擇保留一個它可以是一個簡單的選擇：

jdbc.hive.testOnBorrow=true
jdbc.hive.validationQuery=SELECT 1

如果您希望使用testWhileIdle ，則可以使用以下命令：

jdbc.testWhileIdle=true
jdbc.minEvictableIdleTimeMillis=1800000
jdbc.timeBetweenEvictionRunsMillis=1800000`