- - PR -
セッションに登録したコネクションオブジェクトの接続プールへの返却方法について
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2003-09-01 20:38
EUC-JPでもShift_JIS(今のところは)でもX0201カナは普通に表現できます。 普通に表現できるものを「使わない方がよい」とおっしゃる以上何か 理由があるのだと思って伺ったわけです。 ISO-2022-JPではX0201カナを使用しないと明記されており(RFC1468)、 それ故電子メールでは半角カナを使用すべきでないというのは理解していますが、 たとえばここのようにEUC-JPで書かれていることが明示されたWEBページに X0201カナが現れることは特におかしいと思いません。まぁ、僕は使いませんが。 いやぁ、あまりに話題がずれましたね。失礼しました。 | ||||||||
|
投稿日時: 2003-09-01 20:53
おそらく全く解決していないです。 各Sessionそれぞれにつき別々にHttpSessionBindingListenerインスタンスが 生成されているという前提で書かれていますが、 どこにもそんな保証は無いです。 （むしろServletインスタンスのように、複数のセッションの イベントを一つのHttpSessionBindingListenerインスタンスで 受け持つというのが自然な実装のような気がします） また、仮に各Sessionにそれぞれ別のHttpSessionBindingListenerインスタンスが 割り当てられていたとしても、皆さんが指摘しておられる「SessionにConnectionを 格納することの問題点」がすべてそのまま当てはまります。
>あと、みなさまの意見で大半をしめたのが一回一回select文を投げると 幾つかある選択肢のうちの一つである、とも書きましたよね。それは理解していらっしゃるものとして、、、 これはこれで大きな話題なので新しいスレッド（記事）として 要件を整理して投稿されると良いと思いますよ。実現方法はいろいろあります。 なかなか興味深い話題です。皆さんからいろいろな意見を聞くことができるでしょう(^^) [ メッセージ編集済み 編集者: kito 編集日時 2003-09-01 21:08 ] | ||||||||
|
投稿日時: 2003-09-01 21:36
あ〜すみません。HttpSessionListenerと混同してました。 HttpSessionBindingListenerはSessionに格納するObjectに implementsするものなんですね。 まぁ、それでも茨の道に違いありません(^^; （少し言い換え） 仮にこれでConnectionをうまく管理できたとしても、 皆さんが指摘しておられる「SessionにConnectionを格納することの問題点」が すべてそのまま当てはまります。 結局のところ、何の問題解決にもならないことになります。 | ||||||||
|
投稿日時: 2003-09-02 01:08
一画面コッキリの表示でよければ、sessionをつかわずに requestを使うこともできます。 パフォーマンスに関してはSQLそのもののチューニングが必要な場合、 実行計画を出し、INDEXをはる or SQLを直す です。 WEBアプリで何百万件も扱う表示が必要ですか？ WEBの基本は 小さなトランザクション、大きなトランザクション量です。 | ||||||||
|
投稿日時: 2003-09-02 09:38
下記ソースは、前回のせたソースを呼び出すStrutsのアクションクラスですが SessionData data; data = new SessionData(); hs.setAttribute("data",data); の部分でセッションごとに SessionDataのオブジェクトを作成しています。 このため、このグローバル変数は各々のセッションでしか参照されません。 ちょっとこの部分のソースを前回載せていなかったので誤解が生じたのかも しれません・・・ｍ（＿ ＿）ｍペコリンコ もし static変数でコネクション等を宣言していれば、スレッドセーフに なるように設計しないといけないですよね。 public class KensakuAction extends Action { public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) { HttpSession hs = request.getSession(true); ---------------<省略>--------------- SessionData data; data = new SessionData(); hs.setAttribute("data",data); String target = "success"; return (mapping.findForward(target)); } } [ メッセージ編集済み 編集者: 忍者鳥取県 編集日時 2003-09-02 09:40 ] | ||||||||
|
投稿日時: 2003-09-02 10:02
＊＊＊＊ kitoさんに質問 ＊＊＊＊ kitoさんのおっしゃる、 『皆さんが指摘しておられる「SessionにConnectionを格納することの問題点」』 とは、なにを指しているんでしょうか？ このレスをみて再度このスレッドの投稿を読み返しましたが、 コネクションをセッションに登録することの問題点として 『コネクションの管理がちゃんとできるのか？』 といったことが挙げられていたと思います。 今回のコーディングでこの問題も クリアできていると理解しているのですが・・・・。 ほかにどのような問題がありますか？ スレッドのはじめのほうにも書きましたが、 この業界での経験が浅いので、何分ほかのひとの 意見をよく理解できていないのかもしれません・・・。 結局のところ、何がどう解決していないのでしょうか？ 具体的に教えてください。宜しくお願いします。 [ メッセージ編集済み 編集者: 忍者鳥取県 編集日時 2003-09-02 10:34 ] | ||||||||
|
投稿日時: 2003-09-02 10:17
えー 以前にＷｅｂアプリケーションでコネクションを セッションに登録して使ってはいけないのはなぜかと伺いましたが いまだに takuさんよりご回答頂けてないんですけど・・・・（＾＾ ；） うーん 具体的な理由教えていただけないでしょうかねー？ [ メッセージ編集済み 編集者: 忍者鳥取県 編集日時 2003-09-02 10:42 ] | ||||||||
|
投稿日時: 2003-09-02 10:42
コネクションの最大数は設定により決められるわけで、その数を超えて同時にＤＢに接続することはできません。したがって、一度つかんだコネクションは、不要になった時点で速やかに解放した方が、より多くのユーザがそのアプリケーションを使用でき得るわけです。
一般的に、 （リクエストオブジェクトの生存時間）＜（セッションオブジェクトの生存時間） なので、コネクションはリクエスト単位で使用した方がそのアプリケーションの可用性がより高くなります。 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。