java和mysql實現過期檢測的簡單介紹

本文目錄一覽：

• 1、java處理mysql日期問題
• 2、JAVA連mysql
• 3、java連接mysql資料庫超時的問題誰遇到過?

java處理mysql日期問題

你還能用util.date的格式存進去么？是sql.date吧

所以在取出來的時候，使用sql.date接收就行了

如果需要改變格式的話，先轉換成字元串就好了

JAVA連mysql

查看了Mysql的文檔，以及Connector/J的文檔以及在線說明發現，出現這種異常的原因是：Mysql伺服器默認的「wait_timeout」是8小時，也就是說一個connection空閑超過8個小時，Mysql將自動斷開該 connection。這就是問題的所在，在C3P0 pools中的connections如果空閑超過8小時，Mysql將其斷開，而C3P0並不知道該connection已經失效，如果這時有 Client請求connection，C3P0將該失效的Connection提供給Client，將會造成上面的異常。

上網搜索，在MySQL的論壇上找到一個辦法，就是如果在執行sql語句的時候發生了上述異常，就將sql語句重新執行一次。

試驗發現，這個辦法對這個使用spring+hibernate的服務無效。

進一步搜索發現，MySQL官方不推薦使用autoReconnect=true，參見

需要另外找別的辦法來解決這個問題。

由於問題產生的根本原因在於服務到資料庫的連接長時間沒活動，既然重新連接的辦法無效，就可以嘗試另外一種辦法，就是反空閑。

自己寫一個線程來反空閑的話，比較麻煩。

最後在網上找到一個辦法。為hibernate配置連接池，推薦用c3p0，然後配置c3p0的反空閑設置idle_test_period，只要小於MySQL的wait timeout即可。

在hibernate.cfg.xml中增加下面幾項：

!– configuration pool via c3p0–

property name=”hibernate.connection.provider_class”org.hibernate.connection.C3P0ConnectionProvider/property

property name=”c3p0.min_size”5/property

property name=”c3p0.max_size”30/property

property name=”c3p0.time_out”1800/property !– seconds –!– default: 0 —

property name=”c3p0.max_statement”50/property !– default: 0 —

property name=”c3p0.acquire_increment”1/property !– default: 1 —

property name=”c3p0.idle_test_period”120/property !– seconds –!– default: 0 —

property name=”c3p0.validate”true/property

修改完後測試，問題解決。

——————————————————–

DBCP連接池說明:

driverClassName

url

username

password

上面四個分別是驅動,連接字元串,用戶名和密碼

maxActive 連接池支持的最大連接數

maxIdle 連接池中最多可空閑maxIdle個連接

minIdle 連接池中最少空閑maxIdle個連接

initialSize 初始化連接數目

maxWait 連接池中連接用完時,新的請求等待時間,毫秒

timeBetweenEvictionRunsMillis timeBetweenEvictionRunsMillis和minEvictableIdleTimeMillis一起使用,每

timeBetweenEvictionRunsMillis毫秒秒檢查一次連接池中空閑的連接,把空閑時間超過minEvictableIdleTimeMillis毫秒的連接斷開,直到連接池中的連接數到minIdle為止

minEvictableIdleTimeMillis 連接池中連接可空閑的時間,毫秒

removeAbandoned true,false,是否清理removeAbandonedTimeout秒沒有使用的活動連接,清理後並沒有放回連接池

removeAbandonedTimeout 活動連接的最大空閑時間

logAbandoned true,false,連接池收回空閑的活動連接時是否列印消息

minEvictableIdleTimeMillis,removeAbandonedTimeout這兩個參數針對的連接對象不一樣,minEvictableIdleTimeMillis針對連接池中的連接對象,removeAbandonedTimeout針對未被close的活動連接.

c3p0連接池說明:

driverClass

jdbcUrl

user

password

minPoolSize

maxPoolSize

initialPoolSize

acquireIncrement 池中沒有空閑連接時,一次請求獲取的連接數

maxIdleTime 池中連接最大空閑時間

acquireRetryAttempts 獲取連接失敗後,重新嘗試的次數

acquireRetryDelay 嘗試連接間隔時間,毫秒

checkoutTimeout 等待連接時間,0為無限等待,毫秒

DebugUnreturnedConnectionStackTraces true,false,是否收回未返回的活動連接

unreturnedConnectionTimeout 活動連接的時間.

jdbcurl建議不要使用autoReconnect=true。

———————————————————————-

session.close();沒有調用connection.close()嗎？

如果你的Connection來自於連接池，他只不過被歸還給池了，確實沒有物理關閉，這是正常的結果。

若調用connection.close(), 此連接對象是關閉，還是沒有關閉，只返回給了連接池 ?

那要看連接池的實現了。一般都是返回給連接池，因為新建連接的開銷太大了。

創建一個SessionFactry就對應一個Connection,面SessionFactory中的Session是共享Connection .所以關閉Session對Connection沒有影響的.

資料庫連結池不過就是一個特殊的對象池而已。 對象池的作用就是避免你直接new資源性的對象，降低開銷。把連結返回給連結池就是釋放對該對象池中該Connection對象的引用，這樣，這個對象可以給再次被別人使用。 你調用conn.close()，僅僅是釋放了引用而已，不會關閉物理的連接。

connection對像在鏈接池中複寫了close方法，所以並沒有真正意義上的關閉。明白了吧。當然不同的鏈接池有不同的實現方法，connection只是一個介面，不同的鏈接池實現類是不一樣的，只是我們感覺不到罷了。

java連接mysql資料庫超時的問題誰遇到過?

推測你指的是mysql伺服器的超時吧。默認情況8小時無訪問mysql會斷開連接。通過改配置文件可以改變這個值，但是實際測試效果不好。

mysql方面不好解決就在client端想辦法，大多數鏈接池可以配置在取得鏈接時檢測可用性(據說c3p0連接池可以自動解決，我用的dbcp需要配置)，比如ibatis可以在datasource配置加上property

name=”validationQuery”

value=”select

1

from

dual”/

property

name=”testOnBorrow”

value=”true”/