tomcat連接池的三個重要參數

引用:

a   如果設為true則tomcat自動檢查恢復重新利用沒有正常關閉的Connection（默認是false）
  <parameter>
  <name>removeAbandoned</name>
  <value>true</value>
  </parameter>
b   設定連接在多少秒內被認為是放棄的連接即可進行恢復利用
  <parameter>
  <name>removeAbandonedTimeout</name>
  <value></value>
  </parameter>
c   輸出回收的日志可以詳細打印出異常從而發現是在那裡發生了洩漏
  <parameter>
  <name>logAbandoned</name>
  <value>true</value>
  </parameter>

    實驗環境tomcat配置連接池最大連接數為
代碼如下
 
<parameter>
                <name>maxActive</name>
                <value></value>             
            </parameter>
            <parameter>
                <name>maxIdle</name>
                <value></value>              
            </parameter>
            <parameter>
                <name>maxWait</name>
                <value></value>          
            </parameter>
            <parameter>
                <name>removeAbandoned</name>
                <value>true</value>
            </parameter>
            <parameter>
                 <name>removeAbandonedTimeout</name>
                 <value></value>
            </parameter>
            <parameter>
                 <name>logAbandoned</name>
                 <value>true</value>
            </parameter>使用如下代碼進行實驗（每一次不關閉連接）

try {
    Connection con = getJdbcDAO()getDataSource()getConnection();
    ResultSet rs = concreateStatement()executeQuery(select * from K_MSB_MSPBXX);
    while (rsnext()) {
        Systemoutprintln(rsgetString());
    }
} catch (SQLException e) {
     eprintStackTrace();
}

    當該連續執行次之後後台就報連接池滿的錯

:: [orghibernateutilJDBCExceptionReporter][WARN] SQL Error: SQLState: null
:: [orghibernateutilJDBCExceptionReporter][ERROR] Cannot get a connection pool exhausted
:: [orghibernateutilJDBCExceptionReporter][WARN] SQL Error: SQLState: null
:: [orghibernateutilJDBCExceptionReporter][ERROR] Cannot get a connection pool exhausted

    根據如下腳本查數據庫連接

declare cur_spid cursor 
for
select spid from sysprocesses where ipaddr= and program_name <> SQL_Advantage
go
declare @spid Integer
open  cur_spid
fetch cur_spid into @spid 
while @@sqlstatus=
begin
        print %!  @spid
  dbcc traceon()
  dbcc sqltext(@spid )
  fetch cur_spid into @spid 
end
close cur_spid

 

    得到類似如下的五條記錄即有個連接沒有釋放

引用:

DBCC execution completed If DBCC printed error messages contact a user with System Administrator (SA) role
SQL Text: select * from K_MSB_MSPBXX
DBCC execution completed If DBCC printed error messages contact a user with System Administrator (SA) role

    如果繼續執行該代碼後台就報如下錯提示哪裡的代碼沒有關閉連接(已經具體到那一行代碼獲取的連接沒有關閉這個很重要！！！下面紅顏色標注的異常點信息就是具體連接沒有釋放的代碼信息）

 

DBCP object created :: by the following code was never closed:
javalangException
        at monsdbcpAbandonedTraceinit(AbandonedTracejava:)
        at monsdbcpAbandonedTrace<init>(AbandonedTracejava:)
        at monsdbcpDelegatingResultSet<init>(DelegatingResultSetjava:)
        at monsdbcpDelegatingResultSetwrapResultSet(DelegatingResultSetjava:)
        at monsdbcpDelegatingStatementexecuteQuery(DelegatingStatementjava:)
        at comthunisoftfyspxtSpxtBaseLogiccreatePbxx(SpxtBaseLogicjava:)

    如果時間超過removeAbandonedTimeout設置的時間再直接使用上面的sql腳本查看數據庫連接發現已經都被釋放了並且如果再進行其他數據庫操作已經不報連接池滿的問題說明過了秒之後tomcat會把那些它認為沒有釋放的連接進行釋放

    然後同樣的java代碼把tomcat連接池的那三個參數去掉之後執行次之後也報連接池滿但是再次執行就不能獲取新的連接並且後台的日志都是連接池滿的信息而沒有具體那一行代碼的連接沒有釋放的異常信息

    因為大興實際環境還是出現連接池滿的問題（基本上兩天報一次）准備把這三個參數放到實際環境中試試然後看看後台日志一是想得到具體是哪些地方的代碼沒有釋放二是如果設置removeAbandonedTimeout參數可以避免連接沒有釋放的問題當然個人認為三期代碼的最終部署環境是不需要該參數的在程序中把連接釋放才是解決問題的最根本辦法另外目前還不知道這三個參數會對tomcat性能造成什麼影響應該不大
From:http://tw.wingwit.com/Article/program/Java/ky/201311/28004.html