以下は、Webアプリケーション環境でのデータベース接続に使用できるさまざまな手法です。Webアプリケーションでのデータベース接続
Application Context Database Connection:すべての要求で1つのデータベース接続が共有されます。Database Pooling:固定数のデータベース接続を開き、すべての要求間で接続を共有します。New Database Connection per request:リクエストごとに接続を開きます。これらの手法の利点と欠点は何ですか？開発者はどちらを使うべきですか？
オプション1.すべてのWebユーザー間で単一のデータベース接続を共有することは、何らかの理由で失敗する可能性があります。 1つの長時間実行されるクエリとサーバー全体が停止します。 Webアプリケーション以外のアプリケーションでさえも、現代的なアプリケーションの99.9％で難しく高速です。
オプション2.接続プーリング。おそらく、WebアプリケーションがDBに接続するために2番目に一般的に使用されるテクニックです。 DBとPool/webアプリケーションが同じマシン上にある場合は、まず利点が極端に制限されます。しかし、プールとウェブアプリケーションは同じハードウェア上に簡単に存在することができます。ここでの利点は、データベースの接続にはオープンするのに費用がかかり、その程度は低く、オープンにするのにはコストがかかります。接続を開くには、CPU使用率とメモリ割り当てが必要です。プーリング接続では、数十件の接続をほぼ即座に「接続」できるようにすることができます。メモリは既に割り当てられており、セットアップ作業のほとんどはすでに完了しているため、プールに接続したり切断したりするのは比較的手間がかかりません。プールは通常、特定の数の接続を常時開いておき、トラフィックが増加するにつれて大きくなります。過度のトラフィックが発生した場合、プールは一般的にDBに過負荷がかからないように接続要求をキューに入れます。キューの後ろのユーザーは遅延を経験しますが、システムが停止し、一般にメモリが不足して停止する可能性は低くなりますディスクスワップ
オプション3.リクエストごとに新しいデータベース接続。軽から適度に利用されているシステムでは、ひどい選択肢ではなく、通常、後でプーラーにアップグレードするのは簡単です。ただし、各データベース接続（ページロードごとに）では、CPUとメモリの割り当てを含むDB接続の開閉が必要になることに注意してください。実際には、ページがすばやく読み込まれ、ユーザーベースが小さく、一貫性があり、トラフィックがかなり安定していれば、正常に動作することができます。多くのDEV、CAT、QA環境は、プーラーなしで直接接続されています。欠点は＃1です.DBへの接続を制御する方法はまったくありません。クエリがハングアップすると、何百もの接続が突然DBを強制終了させ、場合によってはDBを再起動または再起動して状況を修正する必要があります。
例：サイトのホームページに1つの不適切なクエリを書き込むと、0.3秒ではなく3秒かかることがあります。最終的には、1ページで1〜2ページが実行されていたサイトでは、最大10〜20個のバンプが発生する可能性があります。今では10-20ページ= 10-20 DB接続の開閉が常時で、10-20が平均で開かれています。この問題は、接続の限界に達するまで、より多くのメモリを使用して這い上がります（または悪いことに、今交換しているすべてのメモリとすべてのメモリを使い切ります）。この時点で、すべてが停止してしまいます。
接続はDBとアプリケーションサーバー/プーラーの両方でリソースを消費することに注意してください。あなたのDBがディスクにページングしているとき、ほとんどの場合、何かをリセットせずに優雅な回復のためにすべての希望が失われます - 明らかに問題は起こりますが、コード修正がなければ、通常はリブートして問題が避けられないほどもう一度やり直してください。うまくいけば、あなたは悪いクエリ、あるいは悪い設定を見つけてそれを修正しました。
オプション2は、ほとんどのオプションを提供します。通常は管理上の頭痛ではありませんが、1台のマシンですべて実行している場合、利益は限られています。少なくとも2台のマシン（アプリケーションサーバーとDBサーバー）を使用している場合は、通常は多数のシステム過負荷を防ぐ簡単なソリューションです。