MySQL 的默認設置下,當一個連接的空閑時間超過8小時后,MySQL 就會斷開該連接,而 c3p0 連接池則以為該被斷開的連接依然有效。
假設你的數(shù)據(jù)庫是mysql,如果數(shù)據(jù)源配置不當,將可能發(fā)生經(jīng)典的“8小時問題”。原因是mysql在默認情況下,如果發(fā)現(xiàn)一個連接的空閑時間超過8小時,將會在數(shù)據(jù)庫端自動關閉這個連接。而數(shù)據(jù)源并不知道這個連接已經(jīng)關閉了,當它將這個無用的連接返回給某個dao時,dao就會報無法獲取connection異常。
如果采用dbcp的默認配置,由于testOnBorrow屬性的默認值是true,數(shù)據(jù)源在將連接交給dao前,會事先檢測這個連接是否是好的,如果連接有問題(在數(shù)據(jù)庫端被關閉),則會取一個其他的連接給dao。所以并不會有“8小時問題”。如果每次將連接交給dao時都檢測連接的有效性,在高并發(fā)的應用中將會帶來性能的問題,因為它會需要更多的數(shù)據(jù)庫訪問請求。
一種推薦的高效的方式是:將testOnBorrow設置為false,而將“testWhileIdle”設置為true,再設置好testBetweenEvictionRunsMillis值(小于8小時)。那些被mysql關閉的連接就可以別清除出去,避免“8小時問題”。
當然,mysql本身也能調(diào)整interactive-timeout(以秒為單位)配置參數(shù),更改空閑連接的過期時間。所以,在設置timeBetweenEvictionRunsmMillis值時,必須首先獲知mysql的空閑連接的最大過期時間。
c3p0對于有效連接的檢測,請參照dbcp配置方式。
以上所述就是本文的全部內(nèi)容了,希望大家能夠喜歡。
新聞熱點
疑難解答
圖片精選