帶C3P0或DBCP的Spring ORM正在泄漏連接

Question

在最新版本的DBCP和C3P0上，使用Spring的Ibatis支持，我遇到了兩個泄漏連接的問題。

該方案是有一個運行SQL的日誌鎖定多個表。這會導致我的池中的連接在用戶觸發鎖定表的查詢時最大化。最後，管理員進入MySQL並在長時間運行的SQL上執行kill query <id>。

如果有足夠的線程（在我的周圍50個或更多的情況下），它正在等待繞了DB線程在游泳池進行檢查回來，然後我看到類似線程轉儲如下：

java.lang.Thread.State: WAITING (on object monitor) 
    at java.lang.Object.wait(Native Method) 
    at com.mchange.v2.resourcepool.BasicResourcePool.awaitAvailable(BasicResourcePool.java:1315) 
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResource(BasicResourcePool.java:557) 
    - locked <0x00002aaacbb01118> (a com.mchange.v2.resourcepool.BasicResourcePool) 
    at com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:477) 
    at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:525) 
    at com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getConnection(AbstractPoolBackedDataSource.java:128) 
    at org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:113) 
    at 

或

java.lang.Thread.State: WAITING (on object monitor) 
    at java.lang.Object.wait(Native Method) 
    at java.lang.Object.wait(Object.java:485) 
    at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1104) 
    - locked <0x00002aab0f030620> (a org.apache.commons.pool.impl.GenericObjectPool$Latch) 
    at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106) 
    at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044) 
    at org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:113) 
    at 

和這些線程等待撒手人寰。

如果該池已最大化，並且只有少數（約5個）線程正在等待池中的空閒連接，則不會發生這種情況。

我知道有配置可以解決這個問題（設置超時等），但我有興趣爲什麼這是發生在第一個地方？爲什麼當有50個或更多的線程在等待連接，並且我終止了長時間運行的SQL時，活動線程不會返回到池中？

更新：我應該明確表示，我使用Spring 3.0.2和 ibatis的2.3。我使用SqlMapClientTemplate，它爲我管理我的 連接。此時，我開始認爲它是 Ibatis 2.3沒有正確處理重負載。

Answer 1

很像@BalusC問，你關閉你的連接嗎？他們應該在您的Java try-catch-finally的finally條款中關閉。每一個的環繞connection.close()方法在自己的try { con.close() } catch (Exception ignore) {}

可選，你應該這樣做的ResultSet然後Statement然後Connection的順序。在您的初始try塊之外聲明您的Connection,Statement和ResultSet作爲null並在您的try塊中實例化。

Connection con = null; 
Statement stmt = null; 
ResultSet rs = null; 

try { 

    con = getConnectionFromPoolMethod(); 

    // ... 
    // instantiate your statement and result set as normal 
    // make your sql call; 
    // extract data from result set to appropriate POJO 

} catch (Exception ex) { 
    // handle your exception, log, wrap, enhance or rethrow or whatever 
} finally { 
    if (rs != null) try { rs.close(); } catch (Exception ignore) {} 
    if (stmt != null) try { stmt.close(); } catch (Exception ignore) {} 
    if (con != null) try { con.close(); } catch (Exception ignore) {} 
} 

如果你爲它，而不是在每個finally一個封裝了SQL調用所有上面的代碼，你可以選擇使用DbUtils實用類Apache Commons DbUtils。

import org.apache.commons.dbutils.DbUtils; 

並應用closeQuietly方法。該finally塊看起來是這樣，而不是：

} finally { 
    DbUtils.closeQuietly(con, stmt, rs); 
} 

Answer 2

只需添加到@ BalusC的評論和@JoshDM's answer，當你調用在你的Java代碼Connectionclose()，幕後這實際上只是檢查連接回您的連接池而不是物理上關閉它。這就是爲什麼始終通過Java代碼關閉連接非常重要的原因，無論底層JDBC驅動程序是否將它們集中在一起。這個在this post

更多的討論。

Answer 3

當使用C3PO，我強烈建議嘗試這種feature。當您在事務外執行數據庫修改時，通常會出現連接泄漏。與未完成寫入的連接無法重用並從池中丟失。如果在相當長的超時時間內啓用此調試，您將能夠看到具有可疑數據庫操作的堆棧跟蹤。

確保在堆棧跟蹤看到的操作正確管理事務。還可以通過將c3p0記錄器設置爲調試級別來監視連接池的使用情況。