[oracle]使用Oracle10g jdbc 驅動中ConnectionCaching所產生的問題的補充

2024-08-29 13:33:10

字體：大中小

來源：轉載

供稿：網友

首先參照 [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。此處通?？梢赃M行共通的修改，即修改點一處。
缺點：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中的系統但還要進行機能變更的時候，所產生的特定問題的特定解決方法而已。汗?。。。。。?！

上一篇：[oracle]使用Oracle10g jdbc 驅動中ConnectionCaching所產生的問題

下一篇：Oracle分頁新招