“com.mysql.jdbc.exceptions.jdbc4.CommunicationsException:Communications link failure Lastpacket sent to the server was 0 ms ago.” |
經(jīng)過一番調(diào)研,發(fā)現(xiàn)很多人都碰到過類似問題,但網(wǎng)上令人滿意的回答并不多。mysql網(wǎng)站上的提問也很多,但并沒有正確答案;百度知道上倒是有一個近似正確的回答?,F(xiàn)將本人的解決辦法總結(jié)一下:
上述問題是由mysql5數(shù)據(jù)庫的配置引起的。mysql5將其連接的等待時間(wait_timeout)缺省為8小時。在其客戶程序中可以這樣來查看其È:
mysql﹥ mysql﹥show global variables like 'wait_timeout'; +---------------+---------+ |Variable_name | Value | +---------------+---------+ |wait_timeout | 28800 | +---------------+---------+ 1row in set (0.00 sec) |
28800seconds,也就是8小時。
如果在wait_timeout秒期間內(nèi),數(shù)據(jù)庫連接(java.sql.Connection)一直處于等待狀態(tài),mysql5就將該連接關(guān)閉。這時,你的Java應(yīng)用的連接池仍然合法地持有該連接的引用。當(dāng)用該連接來進行數(shù)據(jù)庫操作時,就碰到上述錯誤。這解釋了為什么我的程序第二天不能登錄的問題。
你可能會想到在tomcat的數(shù)據(jù)源配置中有沒有辦法解決?的確,在jdbc連接url的配置中,你可以附上“autoReconnect=true”,但這僅對mysql5以前的版本起作用。增加“validationquery”似乎也無濟于事。
本人覺得最簡單的辦法,就是對癥下藥:既然問題是由mysql5的全局變量wait_timeout的缺省È太小引起的,我們將其改大就好了。
查看mysql5的手冊,發(fā)現(xiàn)對wait_timeout的最大È分別是24天/365天(windows/linux)。以windows為例,假設(shè)我們要將其設(shè)為21天,我們只要修改mysql5的配置文件“my.ini”(mysql5installation dir),增加一行:wait_timeout=1814400
需要重新啟動mysql5。
linux系統(tǒng)配置文件:/etc/my.cnf
聲明:本網(wǎng)頁內(nèi)容旨在傳播知識,若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com