程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> MYSQL數據庫 >> 關於MYSQL數據庫 >> Mysql經典的“8小時問題”

Mysql經典的“8小時問題”

編輯:關於MYSQL數據庫

假設你的數據庫是mysql,如果數據源配置不當,將可能發生經典的“8小時問題”。原因是mysql在默認情況下,如果發現一個連接的空閒時間超過8小時,將會在數據庫端自動關閉這個連接。而數據源並不知道這個連接已經關閉了,當它將這個無用的連接返回給某個dao時,dao就會報無法獲取connection異常。

    如果采用dbcp的默認配置,由於testOnBorrow屬性的默認值是true,數據源在將連接交給dao前,會事先檢測這個連接是否是好的,如果連接有問題(在數據庫端被關閉),則會取一個其他的連接給dao。所以並不會有“8小時問題”。如果每次將連接交給dao時都檢測連接的有效性,在高並發的應用中將會帶來性能的問題,因為它會需要更多的數據庫訪問請求。

    一種推薦的高效的方式是:將testOnBorrow設置為false,而將“testWhileIdle”設置為true,再設置好testBetweenEvictionRunsMillis值(小於8小時)。那些被mysql關閉的連接就可以別清除出去,避免“8小時問題”。

    當然,mysql本身也能調整interactive-timeout(以秒為單位)配置參數,更改空閒連接的過期時間。所以,在設置timeBetweenEvictionRunsmMillis值時,必須首先獲知mysql的空閒連接的最大過期時間。

    c3p0對於有效連接的檢測,請參照dbcp配置方式。

以上所述就是本文的全部內容了,希望大家能夠喜歡。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved