###############################################################

#java.sql.SQLException: Connection has been administratively disabled

###############################################################

----------------------------------------

首先我们看看这个pool为什么会被disable? 手工强制suspend连接池、数据库关闭、网络不稳定等因素都可能成为connection pool被disable的诱因。

那么为什么连接中断会引起connection pool被disable呢？这里要谈到两个参数：CountOfTestFailuresTillFlush、CountOfRefreshFailuresTillDisable。这两个参数在weblogic连接池实现

中由于控制是否、何时flush或disable连接池，两个都是指连续几次失败操作（test、refresh）后去flush或disable connection pool。

 

           

           CountOfTestFailuresTillFlush  

            10  

             

           

             CountOfRefreshFailuresTillDisable  

            20  

             

 

----------------------------------------

可以通过netstat看一下db端的连接状态，应该很多处于close_wait状态.

那么Pool什么时候会被重新初始化呢，pool中有一个Healh Maintainece Task，每隔五秒，这个task会启动一次，用于检查那些被disabled的pool，如果连接测试通过，那么这个Pool会被重

新enable。

为什么会出现连接池临时disable的状况呢？问题根源在于test-connections-on-reserve的设定后，当某个连接的idle时间超过SecondsToTrustAnIdlePoolConnection 后，这个连接在返回客

户端之前，会进行连接测试。测试之前，WLS首先会调用checkHang()来检查之前的连接测试是否存在挂起的现象，如果挂起，我们需要disable整个connection pool，同时重新初始化这个连

接池。

 这个实现方式不是很好，于是10.3.4中对这块做了重新设计。我们现在看看10.3.4中是如何实现的吧！ 

        10.3.4引入了一个可配置变量weblogic.resourcepool.max_test_wait_secs，默认为10秒，如果通过-Dweblogic.resourcepool.max_test_wait_secs将它设为0，那么连接测试的时候

，将不再做checkHang。如果这个值不是0，那么checkHang的最长等待时间将是这个指定的值，而不再像10.3.0中，最长等待时间为样本时间*20。同时修改了TYPICAL_TIME_FACTOR，这个值由

1.2变成了10，这个值得修改对suspectHang有一定影响，但影响不大，这个参数也是硬编码的，客户不能对它进行配置。这两个参数中，对checkHang影响比较大的还是

weblogic.resourcepool.max_test_wait_secs，所以如果碰到类似问题，可以通过适当的修改这个值来解决问题。 

java.sql.SQLException: Connection has been administratively disabled. Try again:

----------------------------------------------------------------------------------

Your application should be doing something like this:

myTopJDBCMethod() {

Connection conn = null;

try {

conn = myDS.getConnection(); // test-on-reserve ensures it's working at this instant

...do all the JDBC work...

if the DBMS goes down while you are in this block

the connection you have will be dead. WebLogic

will not replace it automatically. You must close it and

start whatever you wanted to do, all over again,

ideally just calling this method again when/if appropriate

} catch (Exception ouch) {

}

finally {

if (conn != null) try {conn.close();} catch (Exception ignore) {}

}

}

Yes, absolutely, any call to getConnection() after the DBMS is

back up should get a new good connection. Please open an official

support case and we will be eager to fix anything that behaves differently.

Show your pool config.

----------------------------------------

https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1211143.1&id=876004.1&_adf.ctrl-state=zzefo8h32_29&_afrLoop=423839585397765

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=421883986654300&parent=DOCUMENT&sourceId=876004.1&id=1302053.1&_afrWindowMode=0&_adf.ctrl-

state=zzefo8h32_78

http://docs.oracle.com/cd/E14759_01/doc.32/e14143/intro.htm#CHDCAJFC

http://docs.oracle.com/cd/E14759_01/doc.32/e14143/commands.htm#i1074489

java.sql.SQLException: Connection has been administratively disabled. Try again:

----------------------------------------------------------------------------------

Hi Joe,

currently the middleware team has suggested that it might be due to bug no. 8188896:-

8188896 

JDBC 

10.3.1

When JDBC is testing connection pools for hanging connections, it can sometimes disable good connection pools.The test can now take up to 10 seconds by default, and 

this value can be extended or made essentially unlimited by adding the following option to the line that starts Java on the server: 

-Dweblogic.resourcepool.max_test_wait_secs=15 (test can take as long as 15 seconds) 

-Dweblogic.resourcepool.max_test_wait_secs=0 (test can take unlimited time)

How can i make sure that this bug alone is the reason behind this issue? Also can you suggest any quickfix that will help me in meantime to stop the pool from 

disabling itself.

----------------------------------------

 If you will create a MultiDataSource,

and include your regular pool in it's list, the MultiDataSource will permanently

turn off the individual pool's self-disable feature

----------------------------------------

For Cause 2, one workaround is to Increase the value of 'Seconds to Trust an Idle Pool Connection' to reduce the probability that the test is triggered, but not 

completely fix the issue. To fix this issue completely, apply Patch 8174835 on WLS 10.0.0, 10.0.1, or 10.3.0.

For Cause 3, apply Patch 8188896 on WLS 10.0.1, 10.0.2, or 10.3.0.