- - PR -
DBCＰのＤＢセッションについて
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-10-27 20:35
＞かつのりさん
System.out.println(obj_cn.getClass().getClassLoader()); を実行したところnullが入っていたらしくエラーがでました。 ＞taipingさん 追加しましたがなにもおこりませんでした。 ちなみにＴＯＭＣＡＴをアンインストールしてもう一度インストールしたところ エラーが変わって jdbc/oracleのコンテキストにバインドできない というものになってしまいました。 | ||||||||
|
投稿日時: 2004-10-28 09:15
ちょっとたてこんでるので一言だけ、
・・・ということはJNDI lookupがコストのかかる処理であるということは 認識されているわけですよね？ 要はその回数が多いか少ないかが問題だということで良いですか？ | ||||||||
|
投稿日時: 2004-10-28 09:38
大体そんな認識ですが、誤解の無いように言いますと、JNDIのlookupに限らず 何らかの処理を行うと一定のコストが掛かるのは当然です。 だからといって何でもかんでもキャッシュするわけではないですよね？ 個人的な見解としては一回のHTTPRequest中にDataSourceを一回lookupする だけなら大勢に影響ないのでは？と言うことです。 お互いの認識は大体見えてきたと思いますし、具体的な実例として、 DataSourceのlookupは「全然遅くない」「いや、こんなにコストが掛かるんだよ」 と言うデータが出てこない以上、このあたりで議論は終結した方が良いと思います。 すみません。変な議論に巻き込んで。 | ||||||||
|
投稿日時: 2004-10-28 11:50
こんなコードを書いてServletから呼んでみました。
DataSourceの取得を100回行うのに何ミリ秒かかったかを10回測定します。 getDataSource() はキャッシュありで、getDataSource2()はキャッシュなしです。 環境 OS:Windows2000pro CPU:Pentium4 1.4GHz RAM:DDR1GB コンテナ：Tomcat5.0.28 RDB：PostgreSQL7.4(Cygwin上で動作) コンテナとRDBMSは同一ホスト(localhost)上で動作 // DataSource を保持する変数 private static DataSource ds = null; // lookup で使用するJNDI名 private static final String JNDI_NAME = "java:comp/env/jdbc/hogehoge"; private static DataSource getDataSource() throws Exception { if (ds == null) { InitialContext ic = new InitialContext(); ds = (DataSource) ic.lookup(JNDI_NAME); } return ds; } private static DataSource getDataSource2() throws Exception { InitialContext ic = new InitialContext(); ds = (DataSource) ic.lookup(JNDI_NAME); return ds; } public static void connTest() throws Exception { long startTime; long finishedTime; System.out.println("キャッシュあり"); for (int i = 0; i < 10; i++) { startTime = System.currentTimeMillis(); for (int j = 0; j < 100; j++) { getDataSource(); } finishedTime = System.currentTimeMillis(); System.out.println((finishedTime - startTime)); } System.out.println("キャッシュなし"); for (int i = 0; i < 10; i++) { startTime = System.currentTimeMillis(); for (int j = 0; j < 100; j++) { getDataSource2(); } finishedTime = System.currentTimeMillis(); System.out.println((finishedTime - startTime)); } } 結果は以下の通り。 キャッシュなしでも、平均で100回のlookupに27ミリ秒ですから、 これを遅いと思うか気にしないかですね・・・ キャッシュあり 20 0 0 0 0 0 0 0 0 0 キャッシュなし 50 30 20 20 70 10 10 10 20 30 | ||||||||
|
投稿日時: 2004-10-28 12:01
検証ありがとうございます。私のところで手動で実行したのと大体同じ結果ですね。 取り急ぎお礼まで。 | ||||||||
|
投稿日時: 2004-10-29 01:14
あらら・・・
「パフォーマンスに大差が無いからDataSourceに限ってはキャッシュする必要は無い」 という結論に持っていきますか。 なにか釈然としませんが。 その論理だとEJBを使っても同じ結果になりませんか？最近のコンテナなら特に。 （環境によっても大きく変わるでしょうけど） 業務でパフォーマンスチューニングを目指す場面ならそれでも良いかもしれません。 （↑ボトルネックになっていないところは無視する） しかし、おかもとさんの書かれていた「初心者への啓蒙」ということであれば、 「明らかに無駄な処理を行っているところは改善しましょう」 というスタンスの方が良いのではないかと思います。 「無駄な処理であっても、全体のパフォーマンスに影響が少なければ放っておく」 というのはその後で考えることでしょう。 個人的には String s = new String(); などと同じ部類のコーディングに思えます。（かなり極端な例ですが） 個人的には多少のパフォーマンスの差よりも綺麗なコードを書くことを重視するので、 はやりキャッシュすることを薦めます。 それにConnectionを取得しようとする度に毎回InitialContextから作り直すのは 非常に煩雑な作業だと思うのですが、そうではないですかね。 ま、同意してはもらえなさそうな雰囲気なので、議論は終わりで良いです。(^^; | ||||||||
|
投稿日時: 2004-10-29 11:22
一つだけ言っておきます。
上記のような作業はフレームワークで吸収する部分なので、 Connectionを取得するたびにInitialContextから作り直す部分を、 末端の開発者に記述して貰うような不細工なことは絶対にしません！ で、キャッシュするか否かは、その一カ所で判断して切り替えれば 良いと思います。 ではでは。 | ||||||||
|
投稿日時: 2004-10-29 12:48
それと「JNDIのlookupが重いかどうかあなたがどう考えているか?」と何の関係が? 質問に答えずに論点をずらすだけでは対話になりませんよ〜 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。