0

Javaアプリに接続プールを追加しているところです。

このアプリは、さまざまなrdbmsesで動作し、デスクトップアプリとしてもヘッドレスWebサービスとしても動作します。基本的な実装は、デスクトップモード（rdbms = derby）で正常に機能します。Webサービス（rdbms = mysql）として実行している場合、良好な同時動作を得るには接続プールが必要であることがわかります。

私の最初のアプローチは、依存性注入を使用して、起動時に基本的なデータソースと接続プールのデータソースのどちらかを決定することでした。

このシナリオの問題は、connection.close（）をいつ呼び出すかわからないことです。私の理解では、接続プールを使用する場合は、接続オブジェクトをリサイクルできるように、各クエリの後にclose（）を実行する必要があります。ただし、現在の非プーリング実装は、可能な限りConnectionオブジェクトを保持しようとします。

この問題の解決策はありますか？基本的な接続オブジェクトをリサイクルする方法はありますか？スレッドプールされた接続オブジェクトでconnection.close（）を呼び出さないとどうなりますか？

それとも、これら2つの接続戦略を組み合わせるのは単に悪い設計ですか？

4

1 に答える 1

2

私があなたを正しく理解しているなら、本質的にあなたは可能な限り接続を保持することによってあなた自身のプーリングの実装をしているのです。この戦略が成功した場合（つまり、プログラムが説明どおりに動作している場合）、すでに独自のプールがあります。プールを追加することで得られる唯一のことは、新しい接続を確立するときの応答時間を改善することです（実際には接続を確立しないため、プールから取得します）。これは明らかにそれほど頻繁には発生しません。 。

それで、私はこの質問の根底にある仮定に戻ります：あなたの同時パフォーマンスの問題がデータベースプーリングに関連しているのは実際の場合ですか？DerbyではなくMySQLでトランザクションを使用している場合、別の潜在的な原因の例として、同時実行の問題の大きな原因となる可能性があります。

質問に直接答えるには、常にデータベースプールを使用してください。それらはオーバーヘッドが非常に少なく、もちろん、接続を永久に保持するのではなく、接続をすばやく解放するようにコードを変更します（つまり、ユーザーが画面を開いている限りではなく、要求が実行されたとき）。

于 2010-02-23T20:25:27.677 に答える