首先介紹一個JDBC參數(shù)InactiveConnectionTImeout，該參數(shù)用于強制回收那些被泄露的連接(長時間不使用的連接、未被程序正確釋放的連接)，避免連接池因為泄露導致無連接可用。當然該參數(shù)只是起輔助作用，解決問題知道還是在于完善應用程序。

      本文和該參數(shù)有關(guān)，早期的8.1\9.2中，設定該參數(shù)時，定時器(內(nèi)部的連接池維護Task)只會清理那些長期未被使用的空閑連接(從名字上可以看出來)，即對于運行一個長時間執(zhí)行SQL的連接而言，它是不受影響的。但不知道從10.3哪個版本開始(我測試的是10.3.5)，該參數(shù)對于長時間執(zhí)行SQL的連接也進行強制回收了（這個比較不合理，雖然對于正在執(zhí)行的Tx影響不大）。Debug了一下，發(fā)現(xiàn)SQL執(zhí)行時間大于4*InactiveConnectionTimeout時，這個SQL執(zhí)行完成時，會出現(xiàn) <BEA-001153> <Forcibly releasing inactive connection "weblogic.jdbc.wrapper.PoolConnection_oracle_jdbc_driver_T4CConnection@1" back into the connection pool "TestDS", currently reserved by: java.lang.Exception這樣的錯誤。

//該線程為內(nèi)部Task執(zhí)行線程，該線程目前處于被阻塞狀態(tài)，等待SQL執(zhí)行結(jié)束后回收連接
"[STUCK] ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=2 tid=0x2c4d3400 nid=0x1a14 waiting for monitor entry [0x
319bf000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at oracle.jdbc.driver.PhysicalConnection.rollback(PhysicalConnection.java:3896)
        - waiting to lock <0x0e6191d8> (a oracle.jdbc.driver.T4CConnection)
        at weblogic.jdbc.wrapper.Connection.forcedCleanup(Connection.java:156)
        at weblogic.common.resourcepool.ResourcePoolImpl.timeoutInactiveResources(ResourcePoolImpl.java:1955)
        at weblogic.common.resourcepool.ResourcePoolImpl.access$8(ResourcePoolImpl.java:1916)
        at weblogic.common.resourcepool.ResourcePoolImpl$ResourcePoolMaintanenceTask.timerExpired(ResourcePoolImpl.java:2680)
        at weblogic.timers.internal.TimerImpl.run(TimerImpl.java:273)
        at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
        at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)

//該線程為應用執(zhí)行線程，目前該線程SQL正在運行，他阻塞（阻塞對象為T4CConnection）了內(nèi)部Task執(zhí)行線程
"[STUCK] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=2 tid=0x2c7b4c00 nid=0x1100 runnable [0x2cf7e000]
   java.lang.Thread.State: RUNNABLE
        at java.net.SocketInputStream.socketRead0(Native Method)
        ......
        at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1315)
        at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3576)
        at oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:3677)
        - locked <0x0e6191d8> (a oracle.jdbc.driver.T4CConnection)
        at oracle.jdbc.driver.OraclePreparedStatementWrapper.execute(OraclePreparedStatementWrapper.java:1374)
        at weblogic.jdbc.wrapper.PreparedStatement.execute(PreparedStatement.java:102)
        at com.bea.cs.test.jdbc.DriverTest.inactiveTimeoutTest(DriverTest.java:537)
        at jsp_servlet.__ds._jspService(__ds.java:86)

        從上面的線程堆棧可以看到，內(nèi)部Task線程正在調(diào)用connection的rollback，即回滾連接上的本地事務。如果應用線程上使用的連接設為auto commit的話，該SQL執(zhí)行不會被rollback，否則該SQL雖然執(zhí)行完成也會被rollback調(diào)(全局事務中，某個事務分支使用的連接一定是非auto commit的)，所以該問題對涉及全局事務的應用影響比較大。

        下面我們在看看連接被回收的時間點為什么會出現(xiàn)在3-4個InactiveConnectionTimeout之間。當內(nèi)部Task執(zhí)行，發(fā)現(xiàn)到了InactiveConnectionTimeout時間點后，它會調(diào)用timeoutInactiveResources()方法開始進行連接清理。那么為什么正在執(zhí)行SQL的連接會被標志為非活動連接呢？這里涉及連接狀態(tài)的三個標志位，分別為：conn_in_use，connUsed，hang_state，這三個標志位是其中的關(guān)鍵（getUsed()和setUsed()方法中會進行標志位操作及讀取，如果對于某個連接getUsed()返回false的話，該連接會被清理）。下面我們看看其中標志位的變化過程: SQL開始執(zhí)行時，preInvokeHandler會被這三個標志位進行設定。

初始值如下：
conn_in_use-->true
hang_state-->conn_state_in_use
connUsed-->true

第一次InactiveConnectionTimeout檢查，getUsed返回true，同時調(diào)用setUsed(false)，標志位變化如下：
conn_in_use-->true
hang_state-->conn_state_idle_suspect
connUsed-->true

第二次InactiveConnectionTimeout檢查，getUsed返回true，同時調(diào)用setUsed(false)，標志位變化如下：
conn_in_use-->false
hang_state-->conn_state_hang_suspect
connUsed-->false

第三次InactiveConnectionTimeout檢查，getUsed返回true，
hang_state-->conn_state_in_use（從conn_state_hang_suspect變成conn_state_in_use）
同時調(diào)用setUsed(false)，標志位變化如下：
conn_in_use-->false
connUsed-->false
hang_state-->conn_state_idle_suspect（從conn_state_in_use變成conn_state_idle_suspect）

第四次InactiveConnectionTimeout檢查，getUsed返回false，開始回收該連接。

從上面的變化時間點可以看到從第一次到第四次檢查經(jīng)歷了完整的3個InactiveConnectionTimout周期，而從SQL執(zhí)行到第一次檢查點，這個時間小于一個InactiveConnectionTimeout，所以連接開始被回收的時間點介于3-4個InactiveConnectionTimeout之間。