近期发现了Weblogic10.3.5 数据库连接问题,首先介绍一个JDBC参数InactiveConnectionTImeout,该参数用于强制回收那些被泄露的连接(长时间不使用的连接、未被程序正确释放的连接),避免连接池因为泄露导致无连接可用。当然该参数只是起辅助作用,解决问题知道还是在于完善应用程序。
本文和该参数有关,早期的8.1\9.2中,设定该参数时,定时器(内部的连接池维护Task)只会清理那些长期未被使用的空闲连接(从名字上可以看出来),即对于运行一个长时间执行SQL的连接而言,它是不受影响的。但不知道从10.3哪个版本开始(我测试的是10.3.5),该参数对于长时间执行SQL的连接也进行强制回收了(这个比较不合理,虽然对于正在执行的Tx影响不大)。Debug了一下,发现SQL执行时间大于4*InactiveConnectionTimeout时,这个SQL执行完成时,会出现 <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这样的错误。
//该线程为内部Task执行线程,该线程目前处于被阻塞状态,等待SQL执行结束后回收连接
"[STUCK] ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'"
本文和该参数有关,早期的8.1\9.2中,设定该参数时,定时器(内部的连接池维护Task)只会清理那些长期未被使用的空闲连接(从名字上可以看出来),即对于运行一个长时间执行SQL的连接而言,它是不受影响的。但不知道从10.3哪个版本开始(我测试的是10.3.5),该参数对于长时间执行SQL的连接也进行强制回收了(这个比较不合理,虽然对于正在执行的Tx影响不大)。Debug了一下,发现SQL执行时间大于4*InactiveConnectionTimeout时,这个SQL执行完成时,会出现 <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这样的错误。
//该线程为内部Task执行线程,该线程目前处于被阻塞状态,等待SQL执行结束后回收连接
"[STUCK] ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'"