[Seasar-user:2235] Re: ConnectionPoolの不使用について
Koichi Kobayashi
koichik
2005年 6月 23日 (木) 01:23:48 JST
小林 (koichik) です.
Date: Wed, 22 Jun 2005 11:59:35 +0900
From: 加藤太朗 <[E-MAIL ADDRESS DELETED]>
To: [E-MAIL ADDRESS DELETED]
Subject: [Seasar-user:2221] Re: ConnectionPoolの不使用について
> ただ、ヌルポも問題だと思うので、connectionPooolそのものが無い場合は
> getConnection()でnullコネクションを返すなり、seasarの例外を起こすなり
> した方が良いと思います。
設定の不備で getConnection() が null を返すのは賛成しかねます.
それよりは S2DBCP の中でヌルポの方がまだましかと.
より明確な例外を出す方が親切だとは思いますが,S2 が提供する
j2ee.dicon をベースにしていれば普通は設定し忘れるところでは
ないし,Kijimuna も警告を出すはずなので,さほど問題では
ないような.
Date: Wed, 22 Jun 2005 13:55:16 +0900
From: 加藤太朗 <[E-MAIL ADDRESS DELETED]>
To: [E-MAIL ADDRESS DELETED]
Subject: [Seasar-user:2226] Re: ConnectionPoolの不使用について
> うーん… 今のconnectionPoolの実装って connectionManagerとでも
> 言うべき機能と一緒になっちゃっていますね。
> ConnectionWrapperImplとConnectionを透過的に扱う ConnectionManager
> のようなものに機能分離して、ConnectionPoolはその出し入れだけに
> 専任した方が良いような気がしました。
S2JCA のコネクションマネージャはそうなっています.
コネクションマネージャにいわゆるコネクションプールや JTA
トランザクションと連携するためのコンポーネントを差し込んで
任意の構成を設定することができます.
S2JCA-JDBC の 0.1.0 はまさにそんなサンプル.
0.2.0 になるとリソースアダプタの例になるのでその辺りが見えにくく
なりますが.
Date: Wed, 22 Jun 2005 14:44:25 +0900
From: 加藤太朗 <[E-MAIL ADDRESS DELETED]>
To: [E-MAIL ADDRESS DELETED]
Subject: [Seasar-user:2228] Re: ConnectionPoolの不使用について
> DBMS(Postgresです)がある大きなバイナリデータをストリーミングで
> 返している最中にクライアントがHTTPを接続中断した場合でも、コネク
> ションは閉じられないので、DBMSのサーバーは「続きを読み出されるまで」
> そのまま待機している状態になっているようなのです。
ResultSet#getBinaryStream() 等から取得した InputStream をちゃんと
close() してもそうなっちゃうのでしょうか?
> コネクションをプールする際に、コネクションが持っている未読のデータを
> 読み捨てた上で保存してもらえれば問題にならないので、
> もしそういう対応の方がシンプルなら、改善の余地があるか検討いただけると
> 嬉しいです。
うーん,プールから取ってきたコネクションに対するヘルスチェックを
行うのが一般的なやり方だと思いますが,当然ペナルティもあるので
慎重に考えたいところです.
ちなみに S2DBCP は例外を返したコネクションはプールに戻さないように
なっているので,ストリームから読み出した後,プールに戻す前に
適当な SQL を発行することで対処できるかもしれません.
トランザクションのインターセプタの内側にヘルスチェック用の
インターセプタを仕掛けるみたいな感じでどうでしょう?
テストしてませんけど (苦笑) 簡単なインターセプタの実装を
添付しておくので,こいつを該当の処理に weave しちゃってみて
ください.もしコネクションに未読のデータが残っていれば
インターセプタの sql プロパティ (必須) に設定した SQL の実行で
例外がスローされることになり,トランザクションはロールバック,
コネクションは破棄されることになるはずです.
Date: Wed, 22 Jun 2005 16:06:13 +0900
From: 加藤太朗 <[E-MAIL ADDRESS DELETED]>
To: [E-MAIL ADDRESS DELETED]
Subject: [Seasar-user:2232] Re: ConnectionPool の不使用について
> > 今覚えば、LogicalConnectionのほうがより良いとは思いますが。
ちなみに JCA 用語では LogicalConnectionHandle となります.
XAConnection が返す Connection が論理コネクションになるので,
それへのハンドルということらしいです.
Handle と Wrapper...大して変わりませんね.その他では
ConnectionProxy という名前が使われることもあるようです.
つまり,その程度の名前がデファクトみたいな.
> んーでもそのままインターフェース名になるのも、どうでしょう。
> XASupportConnectionぐらいが妥当なのでは。
ConnectionWrapper 自体は XA をサポートしませんよ?
そもそも ConnectionWrapper というインタフェースは通常の利用者が
目にするものではなく,コネクションプーリングを実装するひとかたまりの
コンポーネントの中で使用されるインタフェースです.
そしてそこでの役割は物理コネクションまたは論理コネクションに対する
間接的なアクセスを提供することなので,おかしな名前ではないと思います.
Date: Wed, 22 Jun 2005 17:43:07 +0900
From: 加藤太朗 <[E-MAIL ADDRESS DELETED]>
To: [E-MAIL ADDRESS DELETED]
Subject: [Seasar-user:2234] Re: ConnectionPoolの不使用について
> ただ、maxPoolSizeは、このwhile文(ConnectionPoolImplの90行目辺り)の
> 目的からすると「maxConnectionSize」の誤りではなかろうかと思います。
> 別のプロパティとした方が良いと思います。
似たようなプロパティを増やしても分かりにくいだけなので賛成しかねます.
仮にやるなら int ではなく boolean で enablePooling とかでしょうが,
そうする必要性もないと思います.
> 一応、私が手を入れたものの差分を添付します。参考になれば幸いです。
実は水曜日の朝には対応版を CVS にコミットしてあったのは内緒です (笑).
ちなみに,加藤さんのだとプールに戻さない場合にコネクションが
クローズされないと思います.ConnectionWrapper#closeReally() を
呼び出しましょう.
--
<signature>
<name>Koichi Kobayashi</name>
<e-mail>[E-MAIL ADDRESS DELETED]</e-mail>
</signature>
Seasar-user メーリングリストの案内