首先参照 [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中的系统但还要进行机能变更的时候，所产生的特定问题的特定解决方法而已。 汗！！！！！！！
