MySQL 的默認設置下，當一個連接的空閑時間超過8小時后，MySQL 就會斷開該連接，而 c3p0 連接池則以為該被斷開的連接依然有效。在這種情況下，如果客戶端代碼向 c3p0 連接池請求連接的話，連接池就會把已經失效的連接返回給客戶端，客戶端在使用該失效連接的時候即拋出異常
解決這個問題的辦法有三種：
1. 增加 MySQL 的 wait_timeout 屬性的值。
修改 /etc/mysql/my.cnf文件，在 [mysqld] 節中設置：
# Set a connection to wait 8hours in idle status.
wait_timeout =86400
相關參數，紅色部分
mysql> show variables like '%timeout%';
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| connect_timeout | 5 |
| delayed_insert_timeout | 300 |
| innodb_lock_wait_timeout | 50 |
| interactive_timeout | 28800 |
| net_read_timeout | 30 |
| net_write_timeout | 60 |
| slave_net_timeout | 3600 |
| wait_timeout | 28800 |
+--------------------------+-------+
同一時間，這兩個參數只有一個起作用。到底是哪個參數起作用，和用戶連接時指定的連接參數相關，缺省情況下是使用wait_timeout。我建議是將這兩個參數都修改，以免引起不必要的麻煩。
這兩個參數的默認值是8小時(60*60*8=28800)。我測試過將這兩個參數改為0，結果出人意料，系統自動將這個值設置為。換句話說，不能將該值設置為永久。
將這2個參數設置為24小時(60*60*24=604800)即可。
set interactive_timeout=604800;
set wait_timeout=604800;
2. 減少連接池內連接的生存周期，使之小於上一項中所設置的 wait_timeout 的值。
修改 c3p0 的配置文件，設置：
# How long to keep unused connections around(in seconds)
# Note: MySQL times out idle connections after 8hours(28,800seconds)
# so ensure this value is below MySQL idle timeout
cpool.maxIdleTime=25200
在 Spring 的配置文件中：
<bean id="dataSource"
class="com.mchange.v2.c3p0.ComboPooledDataSource">
<property name="maxIdleTime"value="${cpool.maxIdleTime}"/>
<!--other properties -->
</bean>
3. 定期使用連接池內的連接，使得它們不會因為閑置超時而被 MySQL 斷開。
修改 c3p0 的配置文件，設置：
# Prevent MySQL raise exception after a long idle timecpool.preferredTestQuery='SELECT 1'cpool.idleConnectionTestPeriod=18000cpool.testConnectionOnCheckout=true
修改 Spring 的配置文件：
<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource">
<property name="preferredTestQuery" value="${cpool.preferredTestQuery}"/>
<property name="idleConnectionTestPeriod" value="${cpool.idleConnectionTestPeriod}"/>
<property name="testConnectionOnCheckout" value="${cpool.testConnectionOnCheckout}"/>
<!--other properties --></bean>
附：Mysql經典的“8小時問題”
MySQL 的默認設置下,當一個連接的空閑時間超過8小時后,MySQL 就會斷開該連接,而 c3p0 連接池則以為該被斷開的連接依然有效。
假設你的數據庫是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配置方式。
以上所述就是本文的全部內容了，希望大家能夠喜歡。