引言:昨天晚上做了個(gè)激活服務(wù),然后測(cè)試沒(méi)問(wèn)題,今天早上重新測(cè)了下,發(fā)現(xiàn)報(bào)異常,鏈接不上數(shù)據(jù)庫(kù).
先說(shuō)一下發(fā)生這個(gè)Exception的大致原因：
MySQL的配置中，有一個(gè)叫做“wait_timeout"的參數(shù)，這個(gè)參數(shù)大致的意思是這樣：當(dāng)一個(gè)客戶端連接到MySQL數(shù)據(jù)庫(kù)后，如果客戶端不自己斷開(kāi)，也不做任何操作，MySQL數(shù)據(jù)庫(kù)會(huì)將這個(gè)連接保留"wait_timeout"這么長(zhǎng)時(shí)間（單位是s，默認(rèn)是28800s，也就是8小時(shí)），超過(guò)這個(gè)時(shí)間之后，MySQL數(shù)據(jù)庫(kù)為了節(jié)省資源，就會(huì)在數(shù)據(jù)庫(kù)端斷開(kāi)這個(gè)連接；當(dāng)然，在此過(guò)程中，如果客戶端在這個(gè)連接上有任意的操作，MySQL數(shù)據(jù)庫(kù)都會(huì)重新開(kāi)始計(jì)算這個(gè)時(shí)間。


這么看來(lái)，發(fā)生上面Exception的原因就是因?yàn)槲业姆?wù)器和MySQL數(shù)據(jù)庫(kù)的連接超過(guò)了”wait_timeout"時(shí)間，MySQL服務(wù)器端將其斷開(kāi)了，但是我的程序再次使用這個(gè)連接時(shí)沒(méi)有做任何判斷，所以就掛了。
那這個(gè)問(wèn)題怎么解決呢？
查了下網(wǎng)上的資料,其中詳細(xì)點(diǎn)的如下:


第一個(gè)問(wèn)題：我們的服務(wù)器曾經(jīng)在設(shè)計(jì)的過(guò)程中考慮過(guò)這個(gè)事情，所以服務(wù)器的主線程有一個(gè)定時(shí)的check機(jī)制，每隔半小時(shí)會(huì)發(fā)送一個(gè)"select 1"到數(shù)據(jù)庫(kù)來(lái)保證連接是活動(dòng)的，為什么這個(gè)check機(jī)制不起作用了呢？
第二個(gè)問(wèn)題：從上面的Exception中可以得到這么一個(gè)信息：
[java] view plaincopy
The last packet sent successfully to the server was 43200 milliseconds ago, which is longer than the server configured value of 'wait_timeout'. 這個(gè)信息說(shuō)的很明白，最后一個(gè)成功發(fā)到Server的包是43200毫秒之前。但是43200毫秒才43.2秒，也就是說(shuō)我們的服務(wù)器43.2秒之前才和MySQL服務(wù)器通過(guò)信，怎么會(huì)發(fā)生超過(guò)”wait_timeout“的問(wèn)題呢？而且MySQL數(shù)據(jù)庫(kù)的配置也確實(shí)是28800秒（8小時(shí)），這又是神馬情況呢？[html] view plaincopy org.hibernate.dialect.MySQL5InnoDBDialect
com.mysql.jdbc.Driver true
UTF-8 true

程序中更新的過(guò)程大致是這樣： [java] view plaincopy
session = org.hibernate.SessionFactory.openSession(); transaction = session.beginTransaction();
session.update(something); transaction.commit();
session.close(); 在這里，所有關(guān)于數(shù)據(jù)庫(kù)Connection的連接和關(guān)閉都在Hibernate中，因此，不去挖掘Hibernate的源碼是不可能了。[html] view plaincopy org.hibernate.dialect.MySQL5InnoDBDialect
com.mysql.jdbc.Driver true
UTF-8 true
org.hibernate.connection.C3P0ConnectionProvider
5 20
1800 50
true

上面配置中最重要的就是hibernate.c3p0.testConnectionOnCheckout這個(gè)屬性，它保證了我們前面說(shuō)的每次取出連接時(shí)會(huì)檢查該連接是否被關(guān)閉了。不過(guò)這個(gè)屬性會(huì)對(duì)性能有一些損耗，引用我參考的博客上得話：程序能用是第一，之后才是它的性能（又不是不能容忍）。

當(dāng)然，c3p0自帶類似于select 1這樣的check機(jī)制，但是就像我說(shuō)的，除非你將check機(jī)制的間隔時(shí)間把握的非常好，否則，問(wèn)題是沒(méi)有解決的。

好了，至此，困擾我的問(wèn)題解決完了。希望上面的這些整理可以為我以后碰到類似的問(wèn)題留個(gè)思路，也可以為正在被此問(wèn)題困擾的人提供一絲幫助。

最后補(bǔ)充點(diǎn)東西:

1,一些c3p0的屬性方法總結(jié):

datasource.c3p0.acquireIncrement=10當(dāng)連接池中的連接用完時(shí)，C3P0一次性創(chuàng)建新連接的數(shù)目；

datasource.c3p0.minPoolSize=50連接池中保留的最小連接數(shù)。默認(rèn)為15

datasource.c3p0.maxPoolSize=400連接池中保留的最大連接數(shù)。默認(rèn)為15；

datasource.c3p0.initialPoolSize=50初始化時(shí)創(chuàng)建的連接數(shù)，應(yīng)在minPoolSize與maxPoolSize之間取值。默認(rèn)為3；

datasource.c3p0.maxIdleTime=1800最大空閑時(shí)間，超過(guò)空閑時(shí)間的連接將被丟棄。為0或負(fù)數(shù)則永不丟棄。默認(rèn)為0；

datasource.c3p0.acquireRetryAttempts=100定義在從數(shù)據(jù)庫(kù)獲取新連接失敗后重復(fù)嘗試獲取的次數(shù)，默認(rèn)為30；

datasource.c3p0.acquireRetryDelay=20兩次連接中間隔時(shí)間，單位毫秒，默認(rèn)為1000；

datasource.c3p0.debugUnreturnedConnectionStackTraces=true

datasource.c3p0.maxStatements=0JDBC的標(biāo)準(zhǔn)參數(shù)，用以控制數(shù)據(jù)源內(nèi)加載的PreparedStatement數(shù)量。但由于預(yù)緩存的Statement屬 于單個(gè)Connection而不是整個(gè)連接池。所以設(shè)置這個(gè)參數(shù)需要考慮到多方面的因素，如果maxStatements與 maxStatementsPerConnection均為0，則緩存被關(guān)閉。默認(rèn)為0；

datasource.c3p0.idleConnectionTestPeriod=1800隔多少秒檢查所有連接池中的空閑連接，默認(rèn)為0表示不檢查；

datasource.c3p0.breakAfterAcquireFailure=true獲取連接失敗將會(huì)引起所有等待獲取連接的線程拋出異常。但是數(shù)據(jù)源仍有效保留，并在下次調(diào) 用getConnection()的時(shí)候繼續(xù)嘗試獲取連接。如果設(shè)為true，那么在嘗試獲取連接失敗后該數(shù)據(jù)源將申明已斷開(kāi)并永久關(guān)閉。默認(rèn)為 false；

datasource.c3p0.testConnectionOnCheckout=false因性能消耗大請(qǐng)只在需要的時(shí)候使用它。如果設(shè)為true那么在每個(gè)connection提交的時(shí)候都 將校驗(yàn)其有效性。建議使用idleConnectionTestPeriod或automaticTestTable

datasource.c3p0.autoCommitOnClose=true連接關(guān)閉時(shí)默認(rèn)將所有未提交的操作回滾。默認(rèn)為false；

datasource.c3p0.maxStatementsPerConnection=100連接池內(nèi)單個(gè)連接所擁有的最大緩存Statement數(shù)。默認(rèn)為0；

2,本問(wèn)題中,再多加入1800這一行,原因在上面屬性中有.

3,記得添加兩個(gè)jar包:我添加的版本是c3p0-0.9.2.1.jar和mchange-commons-java-0.2.3.4.jar

若后面有新的問(wèn)題 隨時(shí)補(bǔ)充.

聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com