Java、JDBC連接池、JDBC連接回滾

Question

我們有一個數據庫連接池（java JDBC）。 每次結賬時，我們首先進行搶占式連接回滾，避免連接異常。 請忽略商業案例。 僅從技術角度來看，JDBC 連接回滾是否對應用程序性能影響很大（因為我們的應用程序是毫秒業務）？

Answer 1

我不明白為什么直接來自連接池的連接需要回滾。 他們的 state 必須處於空閑狀態，否則您將無法從池中獲取它們？！

交易對業績有影響。 因此，如果存在無法回滾的事務，則可能有一些查詢無法執行，因為懸空事務阻塞了它們。

因此，如果您的應用程序對時間要求很高 - 您應該花一些時間優化您的代碼。 僅在必要時使用交易。

Answer 2

沒有連接回滾之類的東西。 也許您的意思是事務回滾。 除非您打算丟失在事務中對數據庫所做的任何更改，否則您不應該回滾，並且您不應該提交，除非您打算提交在事務中所做的所有更改。

話雖如此，我不明白“我們首先進行搶先式連接回滾以避免連接異常”這個術語，以及為什么你首先要這樣做。 假設您指的是Connection.rollback()方法調用，我認為這是一種不好的做法。 它實際上會導致性能損失，因為它需要網絡調用，並強制數據庫丟棄關聯事務的 state（這在這種情況下沒有意義，因為尚未完成任何工作）。

如果您打算避免涉及從連接池中檢索到的死連接的異常，則必須在將連接返回給應用程序之前配置池以檢查連接是否過時（通常通過執行測試 SQL 語句）。 一旦應用程序獲得了連接，它不應該在不再需要連接后保留它； 理想情況下，應用程序應該將連接返回到池。 如果您發現自己保留了 object 連接，則底層物理連接無法供其他請求使用，實際上它可能被配置為關閉超過一定時間的連接的防火牆關閉。

Answer 3

完全同意法力。

您從池中“簽出”連接，然后使用它，然后在完成后將其返回給池。

請查看 JBoss 連接池邏輯，或者只是 go 與生產級連接池 package。

在Connection pooling options with JDBC 中有討論：DBCP vs C3P0

Answer 4

驗證來自池的連接的適當方法是使用驗證查詢。 如果回滾是因為有人擔心可能有一個“臟”連接返回到池中，那么您需要使用真正的資源管理框架。