- - PR -
プールされた接続のリセット
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2004-10-15 12:12
以前、ソースとコメントをざっと見ただけなのですが、 minEvictableIdleTimeMillis がそれではないでしょうか。 手元に、こんなメモがあります。 idle object evictor thread アイドル状態の接続を、ある条件の基、プールから立ち退かせるスレッド。 パラメータ: timeBetweenEvictionRunsMillis [-1] idle object evictor スレッドの実行間隔 (ミリ秒) 。 1 未満で無効。 無効の場合、以下のパラメータは意味を持たない。 numTestsPerEvictionRun [3] idle object evictor スレッドの 1 動作中に検査するアイドル接続の数。 0 を指定するのは無意味。 負数の場合は Math.ceil(numIdle / Math.abs(numTestsPerEvictionRun)) 全アイドル接続のうちの何分の 1 を検査するか、という事かな ? minEvictableIdleTimeMillis [1000 * 60 * 30 = 30 分] アイドル接続が、プール中に居座れる時間。 この時間を過ぎると、idle object evictor thread により、破棄される。 1 未満の場合、アイドル状態でもプール中に何時間でも居座れる。 testWhileIdle [false] アイドル接続を validationQuery() で検査し、偽なら破棄される。 minEvictableIdleTimeMillis の検査後に、まだ破棄対象で無い場合に検査される。 * minEvictableIdleTimeMillis=1 未満、且つ testWhileIdle=false は、 何もチェックしない事になるので意味が無い。 検証する時間がないので、間違ってたらすみません。 [ メッセージ編集済み 編集者: はしもと 編集日時 2004-10-15 12:15 ] [ メッセージ編集済み 編集者: はしもと 編集日時 2004-10-15 12:29 ] | ||||
|
投稿日時: 2004-10-15 14:52
はしもとさん、コメントどうもありがとうございます。
多分なんですが、ドキュメントを読む限り、コネクションがある程度 頻繁に再利用される環境だといつまでたっても破棄されないと思うん ですよ。 minEvictableIdleTimeMillisの設定次第なんでしょうが、あまり小さく するのはDB接続のオーバーヘッドを増やすことになりそうですし。 アルゴリズムにもよりますが、いつまで経っても破棄対象にならない コネクションも発生したり。 WebSphere式の設定ができればやっぱりBestですね。 あと、よく考えたらWebLogicの場合も、リセット時点でアクティブな コネクションがどうなるのか記述されてなくて、ちょっと心配。 | ||||
|
投稿日時: 2004-10-15 19:20
あ、一定時間あるいは使用回数毎という事でしたね、すみません。 だとすると、DBCP の設定では無理っぽいですね。 コードを記述して良いなら、DelegatingConnection#getInnermostDelegate() でドライバの返す Connection を得て、それを close() してしまうと 可能かもしれません。 |