オンラインで多くの解決策があるように見える質問を述べるのは嫌いですが、私たちのケースに対して有効なベストプラクティスの解決策を見つけることが実際にはないようで、選択の余地がないと感じました.
使用間隔が数時間から数か月まで異なる場合がある RESTful サーバー アプリケーションを構築しています。
サーバーは Jetty によってホストされています。ORM は使用していませんが、アプリケーションは 3 つの層 (WebService-、Business-、および Data Layer) に階層化されています。データ層は、Guice フレームワークを介して注入された1 つのクラスに存在します。JDBC (MySQL 接続) は、このクラスのコンストラクター内でインスタンス化されます。最初は、Guice がデフォルトで各リクエスト ( ref )で新しいインスタンスを作成することを理解する前に、接続が多すぎて多くの問題がありました。この問題を解決するために、またデータ層クラスはステートフルであるため、クラスを Singleton として注入しました。
接続がタイムアウトし、コンストラクターが 1 回しか呼び出されないため、新しい接続がインスタンス化されないため、REST アプリケーションがしばらく使用されていない場合に問題が発生する可能性があることを予測しました。
現在、複数の解決策がありますが、これを解決する最善の方法を見つけることができないようです。他のソリューションへの意見や提案は大歓迎です。
1. 構成された mysql タイムアウト間隔 を延長する これはベスト プラクティスではないと考えているため、実際には望んでいません。もちろん、リークしている接続オブジェクトがあってはなりませんが、リークがあると、利用可能な接続の空き領域がいっぱいになってしまいます。
2. 各メソッドの最初に新しい接続をインスタンス化し、最後に閉じる これは、私たちが理解している限り、多くのオーバーヘッドを引き起こすため、ベスト プラクティスではありません。
3. インジェクションを「リクエストごと」に戻し、各メソッドの最後にプールを閉じる 新しい接続をインスタンス化するだけでなく、それぞれで新しいオブジェクトをインスタンス化するため、これは #2 よりもさらに悪いことになります。リクエスト？
4. 各メソッドの開始時に接続のステータスを確認し、接続が閉じている場合は新しい接続をインスタンス化します。たとえば、mysql に ping ( example ) を実行し、例外がスローされた場合は新しい接続をインスタンス化します。これは機能しますが、いくらかのオーバーヘッドが発生します。この入力が実際にパフォーマンスに違いをもたらすかどうかについてのアイデアはありますか?
5. 接続がダウンしていることを示すメソッドでスローされた例外を明示的にキャッチし、そうであれば、新しい接続をインスタンス化します 。メソッドが、接続がすでに有効な場合に返されるものを確実に返すようにする方法を見つけます。
6. 接続プール を使用する アプリケーション サーバー (Glassfish など) を使用する場合を除き、接続プールについてはよく知りません。また、これで実際に問題が解決するかどうかも疑問です。そしてそうならば; 接続プールを提供するフレームワークに関する提案はありますか? ここでは、Jetty で PLUS を使用することを提案しています。
不明な点は質問してください。重要な情報を追加するのを忘れている可能性があります。これは私にとっては設計上の問題ですが、コードが役立つと思われる場合は喜んでコードを提供します。
前もって感謝します！