我有幾個服務器進程偶爾響應來自客戶端的消息並執行只讀事務。爲什麼Hibernate/JDBC/MySQL在一天左右之後會斷開連接?
服務器運行幾天後,它們停止正常工作,當我檢查它時,發現有大量關於連接關閉的消息。
當我檢查出來時,事實證明,默認情況下,hibernate工作在某種開發模式下,連接在幾個小時後被丟棄,我開始使用c3po進行連接池。
但是,即使使用c3po,服務器啓動後大約24小時左右也會出現此問題。
有沒有人遇到過這個問題,並知道如何解決它?我對配置休眠的複雜性不夠熟悉。
我有幾個服務器進程偶爾響應來自客戶端的消息並執行只讀事務。爲什麼Hibernate/JDBC/MySQL在一天左右之後會斷開連接?
服務器運行幾天後,它們停止正常工作,當我檢查它時,發現有大量關於連接關閉的消息。
當我檢查出來時,事實證明,默認情況下,hibernate工作在某種開發模式下,連接在幾個小時後被丟棄,我開始使用c3po進行連接池。
但是,即使使用c3po,服務器啓動後大約24小時左右也會出現此問題。
有沒有人遇到過這個問題,並知道如何解決它?我對配置休眠的複雜性不夠熟悉。
MySQL JDBC驅動程序在閒置8小時後超時並丟棄連接。
您可以在您的JDBC URL中設置autoReconnect=true
,如果您嘗試在斷開連接後嘗試查詢,則會導致驅動程序重新連接。但是這有副作用;例如會話狀態和事務不能通過新的連接來維護。
如果使用autoReconnect
,則重新建立JDBC連接,但它不會自動重新執行出現異常的查詢。因此,您需要在應用程序中捕獲SQLException
並重試查詢。
閱讀http://dev.mysql.com/doc/refman/5.0/en/connector-j-reference-configuration-properties.html瞭解更多詳情。
我會建議,在幾乎任何客戶端/服務器設置中,在不需要時將連接保持打開狀態是一個壞主意。
我特別想到DB2/z連接,但它同樣適用於所有服務器(數據庫和其他)。這些連接會消耗可能在其他地方得到最佳利用的服務器資源。
如果您要在企業環境中連接數以萬計的客戶端連接到數據庫時打開連接,那麼您甚至可能會將大型機放在膝蓋上。
我全力爲連接池的想法,但沒有太多嘗試讓單個會話永遠打開的想法。
我的建議如下:
1 /有三類連接在連接池:
2您的連接池是否保持少量的就緒連接,最少爲N,最大爲M.可根據客戶端請求連接的最高速度進行調整。如果就緒連接的數量降至零,則需要更大的N.
3 /當客戶想要連接時,給他們一個準備好的(使其活躍),然後立即打開一個新的,如果現在少於N準備好(但不要讓客戶端等待這個完成,否則你將失去合併的優勢)。這確保了總是有至少N個準備就緒的連接。如果沒有人準備好當客戶想要一個,他們將不得不等待,而你創建一個新的。
4當客戶端連接到活動連接時,如果M連接少於M個,則返回到就緒狀態。否則關閉它。這可以防止您有超過M個就緒連接。
5 /定期回收準備就緒的連接以防止失效的連接。如果有超過N個就緒連接,請關閉最舊的連接。否則關閉它並重新打開另一個。
這具有足夠的準備好和連接池中可用的年輕連接,而不會使服務器過載。
MySql在默認情況下基本超時8小時。
我得到了同樣的異常&解決了3個忙碌的日子後的問題。檢查你是否使用我hibernate3。在此版本中,需要明確提及連接類名稱。還要檢查jar是否在classpath中。檢查步驟如下鏈接&評論
http://hibernatedb.blogspot.com/2009/05/automatic-reconnect-from-hibernate-to.html
刪除autoReconnect=true
我加入放入系統行改變了我的Hibernate的配置文件,它現在爲:
<property name="connection.autoReconnect">true</property>
<property name="connection.autoReconnectForPools">true</property>
<property name="connection.is-connection-validation-required">true</property>
我覺得用C3P0池是更好的和recomanded,但這種解決方案是現在工作,不會出現螞蟻問題。
我讓Tomcat開啓24小時,連接沒有丟失。
請嘗試。
謝謝比爾。我並不擔心會話狀態,因爲我的會話只在需要時打開,然後關閉;無論如何,保持一個開放8小時可能是一個壞主意。 我應該將其配置到JDBL URL中,還是可以通過hibernate屬性配置它? – Uri 2008-11-07 00:21:36
我會在JDBC URL中配置它。 – 2008-11-07 00:26:16