- - PR -
.NETでのC/S型アプリでデータベースアクセス時に接続をオープン/クローズする?
投票結果総投票数:65 | |||
---|---|---|---|
アプリ起動/終了時にオープン・クローズ | 16票 | 24.62% | |
データ操作時にオープン・クローズ | 49票 | 75.38% | |
|
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2004-07-31 19:03
こんにちは。
最近.NETをはじめて、ADO.NETについても情報収集をはじめました。 で、ある.NET系月刊誌にADO.NETについての記述があり、今までのADOとは若干ことなり、 接続系と非接続系という接続方法があることが分かりました。 今まで、C/S型アプリを作る際、データベースへの接続はアプリ起動時、切断はアプリ終了時 に行うような作りとしていました。データベース接続と認証という処理を繰り返し、余分な 負荷をサーバに与えないというのが理由です。 例外的に、不安定回線を使用する際はデータ取得のたびにデータベースの接続/切断を繰り 返すような作りにはしてましたが。 疑問に思ったのは、その雑誌には、ADO.NETではDBに接続したまま処理をしない設計が必要 とあった部分です。非接続型なら分からなくもないですが、接続型での説明でそのような記 述がありました。 みなさんは.NETでのC/S型アプリでADO.NETの接続型の命令を使用する際、データベースへの 接続はどうされていますか? [ メッセージ編集済み 編集者: maru 編集日時 2004-07-31 19:04 ] | ||||
|
投稿日時: 2004-08-02 13:14
DBに繋ぎっぱなしにするのはサーバ及びネットワークに余分な負荷を与えると思います。 「アプリ起動/終了時にオープン・クローズ」と言う設計は、.NETに限らず不可と考えます。 | ||||
|
投稿日時: 2004-08-02 13:38
こんにちは。
恥ずかしながら、この結果(0対19)は私にとっては意外でした。 確かにサーバに接続しっぱなしは、「サーバにユーザセッション接続用のメモリ領域を 保持し続けるという意味でサーバに負荷をかけるからNG」という理由はわかります。 システムの規模や性質によって、サーバへの接続しっぱなしや接続/切断を繰り返す 処理を使い分けたりはします。 特に、(webに比べ)接続数やデータ量やトランザクション量、メモリ使用量を把握しや すいC/S型なら使い分けた方がいいと考えています。 データアクセスのたびに、TCP/IPセッション確立→DBユーザ認証→ユーザメモリ確保 →データ処理→DBクローズ→TCPセッションクローズなどを行うほうが(微々たるもの かもしれませんが)サーバに負荷と応答時間がかかると思っています。 >DBに繋ぎっぱなしにするのはサーバ及びネットワークに余分な負荷を与えると思いま >す。 >「アプリ起動/終了時にオープン・クローズ」と言う設計は、.NETに限らず不可と考え >ます。 具体的にどういった理由から負荷をかけるのか、.NETに限らずNGなのかを教えていた だけないでしょうか?申し訳ありませんが、どうもしっくりきません。 よろしくお願いします。 | ||||
|
投稿日時: 2004-08-02 15:19
> 今まで、C/S型アプリを作る際、データベースへの接続はアプリ起動時、切断はアプリ終了時
> に行うような作りとしていました。データベース接続と認証という処理を繰り返し、余分な > 負荷をサーバに与えないというのが理由です。 最近のデータベースは接続や認証処理が軽くなってきて(軽くする努力がなされて)いますが 接続が集中すればするほどサーバやネットワークに負荷がかかるという事情は変わっていない と思います。対して、接続を維持し続けたとしてもメモリなどの資源を消費しリークする恐れ はあるかもしれませんが、CPUやネットワークにはKeepAlive程度の負荷しかかからないと思い ます。資源の問題に関してはRDBMS側の接続プールの機能である程度対応できると思います。 アプリケーションの中で行われる処理内容にもよりますが、トランザクションの長さをできる だけ短くするようにと同様に絶対にこうでなければなければならないというようなものでもな いように思います。 HTTPはステートレスですが、であるが故にクッキーやSSLなどでセッション管理するわけです よね。個々の処理が完全に独立していれば処理を行う度に接続するという事で良いのでしょうし 独立させましょうという事だと思いますが、RDBMSの種類にもよりますが、フェイル・オーバー やデータベース・リソース・マネージャ、イベント通知など一部の機能を諦める事になる可能 性もあります。 アプリケーションのトレース(デバッグ)や監査、同時接続数、キャパシティ・プランニングが やりにくくなるといった側面もあるかもしれません。 例えば、MS-SQLの場合、SQLプロファイラで見た時に接続毎にProcessIDが違ってきますから 一つのPCで同じEXEが複数同時に動いている場合などは(そのような事があまりないかもしれ ませんが)工夫が必要かもしれません。 特にORACLEの場合は接続毎にトレース・ファイルが分かれてしまうので、Oracle 10gでエンド ツーエンド・トレース、trcsessという新しい機能が追加されました。 XML Web Serviceを介してデータベースとやりとりする場合などは必然的に処理を行う度に データベース接続する事になるでしょうし、本当に必要になった時に接続する、不要になった ら即座に解放するという考え方は大事だと思いますが、選択肢がありどちらでも対応できる という事が重要だと思います。 デザイン・パターンはあまり理解していないので筋違いな事を言っているかもしれませんが、Flyweightパターンはインスタンスを共有できるのであれば、いちいち都度作り直す必要はな いわけですよね。 | ||||
|
投稿日時: 2004-08-03 08:23
厳密には、closeしても接続が切れるわけではありません。接続はコネクションプールに残っており、次に同じ接続文字列、同じユーザ(かつ同じパスワード)での接続要求があると、プールにある接続が使われます。したがって、ご心配されているような(結構大きい)『サーバに負荷と応答時間』は、ほとんどありません。 アプリケーションから見た接続/切断を繰り返すのは、トランザクションの範囲を短くすることで、ダーティーなデータを減らしたり、ロックされている期間を短くする意図もあります。 また、データベースシステムとの接続というリソースを、占有しない、という意図もあります。データベースシステムとの接続数は上限がありますから、データベースシステムも含めてスタンドアローン、というような環境でない限り、色々な意味で高価なリソースを長く占有させるのはどのようなものでしょうか。 | ||||
|
投稿日時: 2004-08-03 09:16
おはようございます。
皆さん返答ありがとうございました。Jittaさんのご説明で理解できました。 今までデータベース系の仕事の大半は下請けで、某大手さんの設計したアプリでも アプリ起動時の接続/切断方式がほとんどだったので、これが当たり前だと思ってい ました。プログラムも作りやすいですし。 ただ、ちょびさんのいわれるように、これが正解というものでもなく、規模やシステム の性質によっては今までのやり方のほうがよい場合もあるような気もします。 | ||||
|
投稿日時: 2004-08-03 09:18
自分は今までアプリケーション起動時に接続を確立して、
ずっとその接続を維持するようにしていたので、この結果には驚きました。 以前、データベース接続のオーバーヘッドがどの程度なのか調べようとして 接続・切断を繰り返すようなコーディングをしたこともあるのですが、 そのときは、ほとんど接続オーバーヘッドはありませんでした。これは、きっと コネクションプールされていたものが再利用されたということでしょうね。 このデータアクセス時に、都度、接続するという方法ですが、 コード記述量の増加、コード可読性の低下を招くと思うのですが、 みなさんは、どのようにしているのでしょうか? (connect, disconnect がソース中にあふれる?) | ||||
|
投稿日時: 2004-08-03 09:30
>このデータアクセス時に、都度、接続するという方法ですが、
>コード記述量の増加、コード可読性の低下を招くと思うのですが、 >みなさんは、どのようにしているのでしょうか? >(connect, disconnect がソース中にあふれる?) 可読性もそうですが、接続/切断制御と状態把握を慎重にしないと、トラブルの元に なりそうですね。 たとえば、あるマスタデータを取得するメソッド内で接続/切断するとして、その メソッドの呼び出し元でも接続/切断すると二重接続でエラーとなりますよね。 メソッドA ↓ 接続 ↓ メソッドB呼び出し | +---→ メソッドB ↓ 接続 ↓ データ処理 ↓ 切断 | +---------+ ↓ データ処理 ↓ 切断 何かよい方法論があるのでしょうが、皆さんはどうされているのでしょうか? |