JDBC 3.0 仕様では、接続 (およびプリペアド ステートメント) プーリングについて説明しています。
接続プールを提供するために DBCP を使用しているスタンドアロンの Java プログラムがいくつかあります (つまり、アプリケーション サーバーは使用していません)。DBCP を使い続ける必要がありますか、それとも JDBC が提供するプーリングを利用して DBCP を取り除くことができますか?
MySQL (Connector/J) を使用しており、最終的には SQL Server サポート (jTDS) を追加する予定です。他のデータベースをサポートする可能性はほとんどありません。
編集: 接続プーリング ライブラリを排除しようとする試みについては、以下のコメントを参照してください。DBCP は依然として関連しているようです (一部のコメンターは、DBCP よりも C3P0 を推奨していることに注意してください)。
他の投稿者の励ましに基づいて、DBCP を排除し、MySQL JDBC ドライバー (Connector/J 5.0.4) を直接使用しようとしました。私はそうすることができませんでした。
ドライバーはプーリングの基盤を提供しますが、最も重要なもの、つまり実際のプールを提供していないようです (これにはソース コードが役に立ちました)。この部分の提供は、アプリケーション サーバーに任されています。
JDBC 3.0 のドキュメントをもう一度見て (「Chapter 11 Connection Pooling」というラベルの付いたものの印刷されたコピーを持っていますが、それがどこから来たのか正確にはわかりません)、MySQL ドライバーが JDBC ドキュメントに従っていることがわかります。
DBCP を見ると、この決定は理にかなっています。優れたプール管理には、多くのオプションがあります。たとえば、未使用の接続をいつパージしますか? どの接続を消去しますか? プール内の最大接続数にハード制限またはソフト制限はありますか? 呼び出し元に接続する前に、接続の「活性」をテストする必要がありますか? 等
概要: スタンドアロンの Java アプリケーションを実行している場合は、接続プーリング ライブラリを使用する必要があります。接続プーリング ライブラリは引き続き使用できます。
DBCP には重大な欠陥があります。特に非常に多くのドライバーがネイティブでプーリングをサポートしている場合は、運用アプリケーションには適していないと思いDataSourceます。
私の場合、ラクダの背中を壊したストローは、データベースへの新しい接続試行が行われている間、プール全体がロックされていることに気付いたときでした。そのため、接続が遅くなったりタイムアウトしたりする原因がデータベースに発生した場合、データベースの使用が完了していても、他のスレッドがプールに接続を戻そうとすると、他のスレッドがブロックされます。
プールは、パフォーマンスを低下させるのではなく、パフォーマンスを向上させることを目的としています。DBCP は単純で、複雑で、時代遅れです。
私は dbcp または c3p0 を使用することを好みます。これらはベンダーに中立だからです。少なくとも mysql や oracle では、標準の sql ではない jdbc クライアントで何かをしようとするたびに、ベンダーのクラスにコンパイル時の依存関係を導入する必要があることがわかりました。たとえば、ここで非常に厄介な例を参照してください。
mysql についてはよくわかりませんが、oracle は接続プーリングに特定の非標準クラスを使用しています。
人々はまだ DBCP を使用していますが、Hibernate のデフォルトになっていると思います。
DBCP は現在のニーズを満たしていませんか?
私はインフラストラクチャを置き換えることを強く信じていません. たとえ新しいまたはより洗練された代替手段があっても、埋められないパフォーマンスまたは機能のギャップがすでに存在する場合を除きます.