誰もが言うように、接続プールを使用する必要があります。なんで?どうした?等。
ソリューションの問題点
昔はいいアイデアだと思っていたので、私はこれを知っています。問題は 2 つあります。
- すべてのスレッド (サーブレット要求はそれぞれ 1 つのスレッドで処理されます) は同じ接続を共有します。したがって、リクエストは一度に 1 つずつ処理されます。これは、単一のブラウザーに座って F5 キーに寄りかかっている場合でも、非常に低速です。試してみてください。これは高レベルで抽象的なように聞こえますが、経験的でテスト可能です。
- 何らかの理由で接続が切断された場合、init メソッドは再度呼び出されません (サーブレットがサービスを停止しないため)。doGet や doPost に try-catch を入れてこの問題を処理しようとしないでください。地獄に落ちてしまうからです (頼まれずにアプリ サーバーを書くようなものです)。
- 考えられることとは反対に、トランザクションの開始は接続だけでなくスレッドに関連付けられるため、トランザクションに問題はありません。私は間違っているかもしれませんが、これはとにかく悪い解決策なので、気にしないでください。
接続プールを使用する理由
接続プールには多くの利点がありますが、何よりも問題を解決します。
- 実際のデータベース接続を確立するにはコストがかかります。接続プールには常にいくつかの余分な接続があり、そのうちの 1 つを提供します。
- 接続が失敗した場合、接続プールは新しい接続を開く方法を知っています
- 非常に重要: すべてのスレッドが独自の接続を取得します。これは、スレッド化が本来あるべき場所、つまり DB レベルで処理されることを意味します。DB は非常に効率的で、同時リクエストを簡単に処理できます。
- その他のもの (JDBC 接続文字列の場所を一元化するなど) ですが、これに関する何百万もの記事、書籍などがあります。
いつ接続を取得するか
サービス デリゲート (doPost、doGet、doDisco など) で開始されたコール スタックのどこかで、接続を取得してから、正しいことを行い、finally ブロックでそれを返す必要があります。finally
C# のメイン アーキテクトが、ブロックの 100 倍以上のブロックを使用する必要があると以前に言ったことに言及しておく必要がありcatch
ます。語られたことのない真実の言葉...
どの接続プール
サーブレットを使用しているため、コンテナーが提供する接続プールを使用する必要があります。接続を取得する方法を除いて、JNDI コードは完全に正常です。私の知る限り、すべてのサーブレット コンテナには接続プールがあります。
上記の回答に対するコメントの一部は、代わりに特定の接続プール API を使用することを提案しています。WAR は移植可能で、「展開するだけ」である必要があります。これは基本的に間違っていると思います。コンテナが提供する接続プールを使用すると、アプリは、複数のマシンにまたがるコンテナや、Java EE 仕様が提供するすべての凝ったものにデプロイできます。はい、コンテナー固有のデプロイメント記述子を作成する必要がありますが、それが EE の方法です。
あるコメンターは、特定のコンテナー提供の接続プールが JDBC ドライバーでは機能しないと述べています (彼/彼女は Websphere について言及しています)。それは完全に大げさでばかげているように聞こえるので、おそらく本当です。そのようなことが起こったときは、「やるべきこと」をすべてゴミ箱に捨てて、できる限りのことをしてください。それは私たちが時々支払われるものです:)