- PR -

セッションに登録したコネクションオブジェクトの接続プールへの返却方法について

参照元記事 | 同じ記事を参照しているスレッド一覧
«前のページへ 1|2|3|4|5|6|7 次のページへ»
投稿者投稿内容
swat
常連さん
会議室デビュー日: 2002/03/21
投稿数: 33
お住まい・勤務地: 埼玉県
投稿日時: 2003-09-02 10:44
引用:

忍者鳥取県さんの書き込み (2003-09-02 10:17) より:
えー　以前にＷｅｂアプリケーションでコネクションを
セッションに登録して使ってはいけないのはなぜかと伺いましたが
いまだに takuさんよりご回答頂けてないんですけど・・・・（＾＾ ；）
具体的な理由教えていただけないでしょかねー？


DBコネクションというリソースをシステム側できっちりハンドリングできないからじゃないですか？
以前、

引用:

説明が足りなくてすみませんでした。
ピーク時の接続数とは、私が現在開発しているＷｅｂアプリケーション
では特定の時間にアクセスが集中します。そのときの接続数のことです。
最大接続数とは、プログラマー側で設定する接続プールできる最大の
コネクションの数のことです。


とおっしゃっていますが、そのこと自体は、

引用:

最大同時利用者数というのが、何を指していっているのか分からないんで、はっきりとしたことはいえないのですが、コネクションプールの数を最大同時利用者数に合わせたとしても、コネクションが枯渇しないとは言い切れませんよ。


の解決策にはなっていないですよね。

コネクションをクライアント側に預けてしまって、それでいてクライアントに使用するコネクションの数を（ひとつに）制限すること、およびコネクションを閉じることを強制する術がないとすれば、それだけで十分な理由だと思いますよ。



[ メッセージ編集済み 編集者: swat 編集日時 2003-09-02 10:46 ]
忍者鳥取県
ベテラン
会議室デビュー日: 2003/08/28
投稿数: 61
お住まい・勤務地: ﾘｵﾈｼﾞｬﾈｲﾛの地下6000Km
投稿日時: 2003-09-02 10:51
引用:

たーぞうさんの書き込み (2003-09-02 10:42) より:
コネクションの最大数は設定により決められるわけで、その数を超えて同時にＤＢに接続することはできません。したがって、一度つかんだコネクションは、不要になった時点で速やかに解放した方が、より多くのユーザがそのアプリケーションを使用でき得るわけです。

一般的に、
（リクエストオブジェクトの生存時間）＜（セッションオブジェクトの生存時間）
なので、コネクションはリクエスト単位で使用した方がそのアプリケーションの可用性がより高くなります。


　確かに　たーぞうさんのおっしゃることもよく分ります。
　しかし、それでは前にも述べました select文とselect文との間に
　更新処理が入ると、整合性がとれないといった問題が生じてきます。
　まーそれぐらい許容して、レスポンスをとるといった選択肢もあると思いますが、
　そこらへんは、そのアプリケーションごとにあった方法を
　とっていくのがベストでしょう。

　　前にも述べましたが、私が作成してるＷｅｂアプリケーションの
　ピーク時に予想されるアクセス数分だけ、コネクションをプール
　させるように設定しますので、レスポンスもそこまで
　問題にならないかと考えます。
たーぞう
ぬし
会議室デビュー日: 2003/08/08
投稿数: 317
お住まい・勤務地: お花畑
投稿日時: 2003-09-02 11:04
なるほど。でもまた
引用:

忍者鳥取県さんの書き込み (2003-08-28 17:19) より:
　たびたびselect文を投げるのもＤＢに多量のデータが存在する場合は
　パフォーマンスが悪くなるように思うのですが、、、

ともおっしゃっておられますよね。
それじゃいっそのこと最初のselectで得たデータをセッションオブジェクトで保持しておいたらいかがですか？ただし今度はセキュリティ上の問題が発生し得ますが・・・
忍者鳥取県
ベテラン
会議室デビュー日: 2003/08/28
投稿数: 61
お住まい・勤務地: ﾘｵﾈｼﾞｬﾈｲﾛの地下6000Km
投稿日時: 2003-09-02 11:08
引用:

swatさんの書き込み (2003-09-02 10:44) より:

DBコネクションというリソースをシステム側できっちりハンドリングできないからじゃないですか？

コネクションをクライアント側に預けてしまって、それでいてクライアントに使用するコネクションの数を（ひとつに）制限すること、およびコネクションを閉じることを強制する術がないとすれば、それだけで十分な理由だと思いますよ。


　このスレッドの２ページ目を見ていただけると分ると思いますが、
　コネクションをクライアント側にあずけるのではなくて、サーバ側で
　セッションのタイムアウト時にコネクションをクローズするように
　することができます。
　　
　『確かにJavaScript云々の話は私が
　　間違っていたと思います。ｍ（＿　＿）ｍペコリンコ』
忍者鳥取県
ベテラン
会議室デビュー日: 2003/08/28
投稿数: 61
お住まい・勤務地: ﾘｵﾈｼﾞｬﾈｲﾛの地下6000Km
投稿日時: 2003-09-02 11:13
引用:

たーぞうさんの書き込み (2003-09-02 11:04) より:

それじゃいっそのこと最初のselectで得たデータをセッションオブジェクトで保持しておいたらいかがですか？ただし今度はセキュリティ上の問題が発生し得ますが・・・


　このスレッドで前にも述べましたが、その場合だとselectを投げた結果として
　多量のデータが存在した場合、セッションに多量のデータが格納されることにより
　相当リソースを消費してしまうと考えられます。

[ メッセージ編集済み 編集者: 忍者鳥取県 編集日時 2003-09-02 11:14 ]
taku
ぬし
会議室デビュー日: 2002/11/12
投稿数: 918
お住まい・勤務地: 墨田区→中野区
投稿日時: 2003-09-02 11:18
引用:

忍者鳥取県さんの書き込み (2003-09-02 10:17) より:
引用:

takuさんの書き込み (2003-08-28 16:53) より:
コーディングを間違えているというより、根本的におかしくないですか？
コネクションをセッションに登録して使いまわしちゃいけませんよ。
コネクションプーリングへのコネクションの返却って、
各リクエスト毎に行うものですよ。
クライアントアプリケーションなら、
ＤＢの接続はアプリケーションが終了するまで、
接続を維持したままで問題ありませんが、
ＷＥＢアプリケーションでそんなことをして大丈夫だと思われますか？


えー　以前にＷｅｂアプリケーションでコネクションを
セッションに登録して使ってはいけないのはなぜかと伺いましたが
いまだに takuさんよりご回答頂けてないんですけど・・・・（＾＾ ；）
具体的な理由教えていただけないでしょかねー？




　名指しですか(^^。
　もう皆さんがだいたい回答しちゃってますよね。
だから後から私が回答することでも無いと思いませんか？
私が終業直前に書き込みをして、次の日に見たら、
だいたい回答されていましたから(^^。
流れを見たら解かってもらえませんかね。

しょうがないので、私が心配していることをちょっと書きますね。
例えば、メモリーリークは大丈夫ですかね。
ＤＢのクローズをしっかりしないだけでも、
メモリーリークが生じることがあるんですが。
私が携わったことがあるプロジェクトで、
サーバーがメモリーリークでダウンしたことがあります。

　だいたい、ステートレスなＨＴＴＰでクライアントとサーバー間の通信を行うのに、
サーバーとＤＢとの通信だけ維持するのはおかしいと思いませんか？
swat
常連さん
会議室デビュー日: 2002/03/21
投稿数: 33
お住まい・勤務地: 埼玉県
投稿日時: 2003-09-02 11:32
引用:

忍者鳥取県さんの書き込み (2003-09-02 11:08) より:

　このスレッドの２ページ目を見ていただけると分ると思いますが、
　コネクションをクライアント側にあずけるのではなくて、サーバ側で
　セッションのタイムアウト時にコネクションをクローズするように
　することができます。
　　
　『確かにJavaScript云々の話は私が
　　間違っていたと思います。ｍ（＿　＿）ｍペコリンコ』


クライアントに預ける、という書き方は観念的だったかもしれませんね。すみません。

セッションタイムアウト時のクローズはいいんですが、結局のところ、ユーザ数＝コネクション数（セッション数といったほうがいいでしょうか）とはなりませんので、いくら設定をユーザ数と同じにしたとしても、枯渇の問題は避けられないかと思いますよ。

たとえば、一人のユーザがブラウザを開いてログイン、検索処理をして、ログアウトをせずブラウザを閉じ、またブラウザを開いてログイン・・・・ということを10回も繰り返せば、サーバ側には、一人のユーザに対して、10個のsessionオブジェクトができ、それぞれに対して、1つずつのDBコネクションがオープンしたまま保持され、それはタイムアウトするまで、クローズされることがない・・・ということになりますよね。
アクセスピーク時のユーザ数＝コネクションプール設定数としていると、アクセスピーク時には、たった一人でもログアウトせずにブラウザを閉じ、再ログインしようとして段階で、枯渇してしまうと思います。

したがって、コネクションプールの設定数が十分だからといって、問題は解決しないと思います。

＃個人的には、こういう設計って、コネクションをプールしてることにならないし、リソースをプレゼンテーション層まで引き上げちゃってるし、ステートレスな通信にステートフルな通信を保持しようって言う時点であまり好きじゃないですね。

[ メッセージ編集済み 編集者: swat 編集日時 2003-09-02 12:07 ]
kito
ベテラン
会議室デビュー日: 2003/03/24
投稿数: 59
お住まい・勤務地: Osaka
投稿日時: 2003-09-02 11:34
引用:

忍者鳥取県さんの書き込み (2003-09-02 10:17) より:
えー　以前にＷｅｂアプリケーションでコネクションを
セッションに登録して使ってはいけないのはなぜかと伺いましたが
いまだに takuさんよりご回答頂けてないんですけど・・・・（＾＾ ；）
うーん　具体的な理由教えていただけないでしょうかねー？

最初の方でukさんやHushさんが指摘しておられますよ。

各所で語り尽くされている話題なのでここで繰り返すのもアレですが(^^;

サーバーにリクエストを投げるだけでセッションは作られますから、
一般には（セッション数 ＞ DB同時接続数）とします。
セッションにDB接続を関連付けてしまうと、1セッションに付1接続必要です。
500回リクエストを投げれば500セッションが生成され、DB接続も500本作られますよね。

DB接続数にあわせてセッション数を減らす？→本当に利用したいユーザーが利用できないですね。
セッション数にあわせてDB接続を増やす？→DBサーバーのリソースを無駄に消費しますね。

悪戯も簡単ですね。WebブラウザからならCookieをOFFにしてリロードを繰り返しましょうか。

DB接続だけ見ても、同時接続数が増えるとライセンス料が高くなったり、
そもそも何百もの接続してDBサーバーは大丈夫？という話にもなります。

どこからも使われないDB-Connectionが大量にほったらかしてある、って感じですかね。
DB接続って貴重なリソースなんですが、もったいないですね(^^)

HttpSessionBindingListenerを調べたとき見つけたのですが、
Servlet/JSPのセッションとリソース管理について
http://www.seraphyware.jp/dev/tips/java.tips.session.html
のページなどは注意点が良くまとまっていて良いと思いました。

引用:

忍者鳥取県さんの書き込み (2003-09-02 10:51) より:
　しかし、それでは前にも述べました select文とselect文との間に
　更新処理が入ると、整合性がとれないといった問題が生じてきます。

そういう要件が本当に必要なら、その点だけ解決すれば良いのではないですか？
既に書きましたが、（そういう動作が適当かどうかは別として、）実現方法はありますよ。
«前のページへ 1|2|3|4|5|6|7 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）