Java中的PostgreSQL持久連接（使用JDBC）

Question

我正在設置一個數據記錄器，該記錄器從一個寧靜的Web服務（從安裝在生產設備上的PLC ）輪詢數據，並且需要將其寫在PostgreSQL數據庫上。

我通常需要每30秒從5台不同的機器（每周24/24小時和每周6天）讀取數據。 如果我決定在查詢后每次都關閉連接，則每天大約有15.000個數據庫連接。 我假設所有5台機器將在不同的時間讀取，但是如果我決定同時讀取所有這些機器，那么我們當然可以將其減少到3.000個查詢。

使用PostgreSQL實現持久連接的最佳方法是什么？ 我的疑問是，創建數據庫“處理程序”類並返回要使用的“連接”對象可能會受到超時或錯誤的影響（當連接自身關閉時，我將無法記錄任何數據）。

Answer 1

共享連接的最佳方法是連接池，例如DBCP 。

如果您有其他機器連接到數據庫，則難度會增加一點。 我會在另一台計算機或其中一台計算機上設置服務。 例如通過REST或其他可能的接口。

最后，請確保還要檢查您的PostgreSQL配置。 一個好的指南可以在postgres Wiki中找到。

Answer 2

保持連接打開

您似乎在說有五個JDBC客戶端，每個客戶端需要每周六天，每天四分之一鍾進行查詢或編寫。 如果是這種情況，我認為根本不需要斷開連接。 只是讓每個JDBC客戶端維護一個開放的連接。

為什么您認為有必要在半分鍾通話之間關閉連接？ 如果要考慮其他因素，請編輯您的問題進行澄清。

確保測試您的JDBC連接，因為它可能會因網絡中斷或Postgres服務器重新啟動而丟失。 如果連接失敗，請打開另一個。

您可以無限期地維護應用程序與Postgres服務器之間的連接。 請記住兩件事：txn超時和網絡的脆弱性。

交易超時

每個客戶端連接都有默認設置 。 其中之一是idle_in_transaction_session_timeout (integer) 。 如果您將事務保留的時間超過此限制，則會回滾該事務，並關閉您的連接（會話）。

如果您知道將長時間打開事務，則可以禁用超時功能。 一般不推薦。 可能與您的用例無關。 如果您完全使用事務，則您的描述聽起來會很簡短。

引用文檔 ：

idle_in_transaction_session_timeout (integer)

用空閑時間超過指定持續時間（以毫秒為單位）的打開事務終止任何會話。 這樣可以釋放該會話持有的所有鎖，並重新使用連接插槽； 它還允許清理僅對該事務可見的元組。 有關更多詳細信息，請參見第24.1節。

默認值0禁用此功能。

網絡的脆弱性

網絡連接本質上是脆弱的。 經驗不足的程序員往往不願接受這種挑戰，因為開發環境往往比實際的部署環境更加可靠。

使用網絡連接時，程序員必須始終格外小心。 請參閱分布式計算的謬論 。 你必須假設你將有網絡中斷和失敗的數據庫連接。 每次工作時都要測試數據庫連接的有效性。 捕獲JDBC驅動程序引發的異常。 在適當的地方使用事務來保護數據的完整性。 這就是發明交易的主要原因：我們期望失敗。

換句話說，您在問題中沒有提到“持久連接”之類的東西。 有簡單的聯系 。 保持打開狀態50毫秒還是50天無關緊要：所有連接隨時都有失敗的風險。 因此，再次期望失敗 。

確保在開發測試周期中測試網絡故障。 有高科技的方法可以做到這一點。 我的一個低技術偏愛：運行時拉以太網電纜。

如果可行，請考慮將應用程序和Postgres服務器部署在同一個盒子上（足夠的內核，足夠的RAM和足夠的穩定性）。 應用程序與數據庫之間的本地連接比跨機器分布（聯網）的可靠性（更快）*得多。 但是其他部署問題可能會要求使用單獨的計算機。 系統管理與權衡取舍有關。

主題

如果在您的應用程序中使用線程，請確保它們不共享JDBC連接。 每個線程應使用自己的連接。

您提到了“數據庫處理程序”以“獲得連接”。 不知道你的意思。 通常，我建議您在其上調用getConnection的DataSource對象。 您的JDBC驅動程序應提供一個實現。

不要使用連接池

人們通常建議使用連接池來進行數據庫工作，有時經常反省地建議使用連接池，而沒有適當考慮其優缺點。 連接池帶來了自己的風險和復雜性。

當有許多客戶端間歇性地調用數據庫時，連接池最有用。 您的情況恰恰相反，很少有客戶經常對數據庫進行多次常規調用。 因此，我想禁止您使用連接池。