プロが教えるわが家の防犯対策術!

struts1.3 + spring1.2 + tomcat + oracleで開発中です。
DBCPでコネクションがプーリングされた状態で、DBが停止・再起動
した場合、DB停止前からプーリングされていたコネクションは
無効になってしまいますが、これの対処はどうするのがベストでしょうか。
(1) testOnBorrow で検査する
→コネクション取得の都度発行される検査用SQLの負荷が心配
(2) testWhileIdle で検査する。
→検査スレッドの起動間隔はどれくらいが適当なのか?
(3) getConnection時に自前でリトライするロジックを組み込む
→WebSphereにある、StaleConnectionExceptionのような例外がある?
(4) もっと別の画期的な方法がある!!

以上、よろしくお願いします。

A 回答 (1件)

こんちわ。



だいぶ昔のことなので忘れてるんですが。。。

そもそもにDBCPが汎用のプールだし、汎用だからJDBCだけを利用してると思うんですが、JDBCのAPIとしてコネクションが有効か否かを検査する術がないので。。。(今はちがう?)。

(1)確実なのはこれだと思います。負荷はちょっとあるでしょうけどシビアなパフォーマンス要件や環境でなければ普通はまともなパフォーマンス、軽微な負荷程度なのではないかと思うです。DBCPの実装が不明なんですが、validationQueryは固定SQLなのでSQLキャッシュもされてパース負荷も少ないでしょうし、行を読まなければ負荷もSQLのパースとかそんな程度のものだろうし。いや1行は必要なのか。。。でもDUAL表を使えばディスクアクセスもないから。やっぱり負荷は少ないんじゃないでしょうか。
ちなみにある案件ではこれを利用しても結構快適でした。
(2)は、ためすしかないんじゃないでしょうか。(1)をやっとけば気にする必要なしとも思います。
(3)は、あったっけ。。。ないんじゃないでしょうか。ちなみにWebSphereではStaleはSQLのexecute時に発生すると記憶してます。getConnection時にはでないようなー。
(4)あったらいいなぁ(w。DB固有のコネクションプールをつかうとか。OracleならそれこそDBCPの代わりみたいなのありそうですけど。。。ないんすかね。
    • good
    • 0
この回答へのお礼

ご回答ありがとうございます。

(1)・・・なるほど、キャッシュもあるしDUAL表を使えば問題なさそうですね。

(3)・・・IBMのサイトに以下の例が載っていますので、StaleConnectionExceptionは、getConnection時に返るものと思われます。
try {
 conn = dataSource.getConnection(user, password);
  :
 (connを使用したSQL処理)
  :
 i = 0;             // リトライのためのカウンターを0にする
} catch (StaleConnectionException scex) {  // Stale Connection を catch
 if (conn != null) {
  try {
   conn.close();       // Stale Connection を close
  } catch (Exception e) {
   e.printStackTrace();
  }
 }
} catch (Exception e) {
  :

(4)・・・OracleConnectionPoolDataSourceなるものがあるようですね。これに再接続の機能があればよいのですが。
調べてみます。
ありがとうございました。

お礼日時:2008/06/14 21:10

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!