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