假設你的資料庫是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配置方式。
nutz mysql8小時 MySQL8小時問題
一 問題 獲取mysql連線，8小時內無請求自動斷開連線。二 解決 2.1 分析 mysql伺服器預設的 wait timeout 是28800秒即8小時，意味著如果乙個連線的空閒時間超過8小時，mysql將自動斷開連線，而連線池卻認為該連線還是有效的，當應用申請使用該連線時，就會導致報錯 2.2 ...
MySQL 8小時連線超時問題
mysql配置當中有個配置項wait timeout，他控制的是如果乙個連線超過指定時間沒有活動，mysql服務端將單方面斷開連線，如果客戶端還保留這個連線，這個連線將不可用，導致客戶端報錯等異常出現，這個值預設等於28800，單位是秒，也就是8個小時。要解決這個問題，有人將配置的值修改到很大，個人...
mysql 8小時時差
一 mysql uroot p 登陸 1.set global time zone 8 00 全域性 2.set time zone 8 00 當前會話 2.flush privileges 生效 二 my.cnf locate my.cnf mysql help grep my.cnf mysql...