Tomcat6とMySQL5.0を使用するJavaSpringMVC2.5アプリケーションがあります。なんらかの理由で、c3p0接続プールで使用される接続の量が制御不能になり始め、最終的にTomcatがダウンするという奇妙なシナリオがあります。
JMXを介してc3p0接続プールを監視しており、ほとんどの場合、接続はほとんど使用されていません。このスパイラル状態が発生すると、Tomcat接続プールが最大になり、apacheがスレッドのキューイングを開始します。
スパイラルシナリオでは、データベースの負荷が低く、エラーや明らかな悪い状況は発生していません。
この問題を検出する方法についてのアイデアが不足し始めています。状況がすでに制御不能になっているときに、Tomcatスタックダンプを実行しても、それが制御不能になる前にどのようにキャッチできるかわからない場合は、何の役にも立たないと思います。
また、ログからは奇妙なことをしているとは思わないテラコッタも使用しています。
どんなアイデアでも大歓迎です！
乾杯！
どこかで接続がリークしています。これは、インプロセストランザクションに関連付けられた接続を取得するのではなく、セッションファクトリからHibernateセッションを明示的に取得する場合に発生する可能性があります（正確なメソッド名を思い出せません）。
C3P0では、2つの構成オプションを使用してこの状況をデバッグできます（以下は、ダウンロードパッケージの一部であるドキュメントからコピーされます）。
unreturnedConnectionTimeoutは、接続がチェックアウトされたままになる時間の制限（秒単位）を定義します。ゼロ以外の値に設定されている場合、この制限を超える未返却のチェックアウトされた接続は、すぐに破棄され、プールで置き換えられます
debugUnreturnedConnectionStackTracesをtrueに設定すると、接続がチェックアウトされるたびにスタックトレースがキャプチャされます。返されていない接続がタイムアウトするたびに、そのスタックトレースが出力され、すぐにチェックインされなかった接続がチェックアウトされた場所が明らかになります。debugUnreturnedConnectionStackTracesは、スタックトレースをキャプチャすると接続のチェックアウトが遅くなる可能性があるため、デバッグにのみ使用することを目的としています。