[oracle]使用Oracle10g jdbc 驱动中ConnectionCaching所产生的问题 的补充

首先参照 [oracle]使用Oracle10g jdbc 驱动中ConnectionCaching所产生的问题 这篇文章，在最后提出的解决方案是在 getConnection之前进行 无效Cache的监测，和更换。

经过实际测试，发现refreshCache的时候，所占用的时间也是一笔不小的开销，每次平均在0.2秒左右，对于一个Action处理中多次getconnction的处理来说，累计起来的时间能够达到一秒之多。

为了解决这个问题，存在两种方案:

1. 对于存在dblink的plsql的action，getconnection之前调用refreshCache。 其他的PLSQL，getconnection之前不调用refreshCache

优点：1。保证plsql的正常调用。不会出现异常。

2。无dblink的plsql ，不需要调用refreshCache，节省了执行时间。

缺点：1。需要对有dblink的plsql的action程序进行各个修改。

2。即使PLSQL没有修改也要调用refreshCache，还是消耗了不必要的时间。

2.在执行plsql后进行特定异常的判断处理，如果是plsql被废弃的异常，调用一次refreshCache处理。

优点：1。保证dblink的plsql变更后只调用一次refreshCache处理，没有消耗不必要的时间。

2。此处通常可以进行共通的修改，即修改点一处。

缺点：1。plsql变更后，必定有一次错误被表示。

2。plsql变更后，必定有一次错误被表示。而这个错误表示的回数上面不确定。因为使用了connectionpool，所以connection越多，这个错误表示的回数上面越不确定

建议解决方法：

因为plsql的变更通常是开发和测试人员进行调试用，所以开发和测试人员更改完plsql后，立刻进行运行中系统这个PLSQL相关程序的执行，使自己看到这个message，即保证cache已经被refresh，这样就不会影响客户访问正在运行的系统的功能。

参考代码：

try {

proc.execute(); // proc is an instance of OracleCallableStatement

} catch (SQLException e) {

String em = e.getMessage();

if(em != null && em.indexOf("ORA-04068") != -1 &&

em.indexOf("ORA-04061") != -1 &&

em.indexOf("ORA-04065") != -1 &&

em.indexOf("ORA-06508") != -1 &&

em.indexOf("ORA-06512") != -1) {

ConnectionManager.refreshCache(); // refreshCache method is what the previous article

throw e;

}

}

总结：

本问题的针对性比较强，对于release中的系统但还要进行机能变更的时候，所产生的特定问题的特定解决方法而已。 汗！！！！！！！