postgresでのSHOWTRANSACTION ISOLATIONLEVELクエリがたくさん
Hibernate 4、PostgreSQL、C3P0を使用しています。
私のWebアプリケーションでは、しばらくすると複数のSHOW TRANSACTION ISOLATION LEVELサーバーがハングする原因となるデータベース内のクエリ。私のコードでは、すべての接続が適切に閉じられています。
接続漏れによるものですか？
また、各クエリのstateも確認する必要があります。これが、idleの場合は、問題がない可能性があります。
pg_stat_activityは、開いている各接続によって実行された最後のクエリを表示します。また、c3p0はSHOW TRANSACTION ISOLATION LEVELを使用して接続を開いたままにします（通常の予想される動作）。
これが起こっていることです：
- 接続が開かれます
SHOW TRANSACTION ISOLATION LEVELは、接続を開いたままにするために実行されます。- 接続プールは、接続を開いたままにするために、このクエリを定期的に（たとえば、10分ごとに）送信します。
- これらのクエリは
pg_stat_activityに表示されます。これは、特定の接続を介して実行された最後のクエリである場合があるためです。また、この接続はアクティブに使用されていないため、idleとして表示されます。
接続プール内の接続をあまりにも速くかき回しているようです。
これは、過度にアグレッシブなmaxIdleTimeまたはmaxConnectionAgeを設定したか、接続が接続テストに失敗して削除されたか、アプリケーションが接続を要求したときに誤ってプールを再構築したことが原因である可能性があります。安定したプールを保持して使用する。 （これは非常に悪いことですが、驚くほどよくある間違いです。）
c3p0は、取得した接続ごとに1回接続分離レベルをチェックします。取得した接続はプール内で長い存続期間を持つ必要があるため、その償却されたオーバーヘッドはごくわずかです。
ただし、構成の問題やバグが原因で、アプリケーションでc3p0が継続的に接続を取得している場合（クライアントごとに1つ、またはクライアントごとにプールを再構築している場合はさらに悪い場合）、トランザクション分離チェックは、根本的な問題の悪化の目に見える症状になる可能性があります。
c3p0でチェックインとチェックアウトのテスト接続をfalseに変更します
サーバーがハングするためにデータベースに複数のSHOWTRANSACTION ISOLATIONLEVELクエリがあります。
これの複数のクエリのためにサーバーがハングするのは本当に難しいです（私は不可能だと思います）。サーバーがハングした場合は、構成を確認し、バージョンで利用可能な最新のマイナーパッチを使用していることを確認する必要があります。
SHOW TRANSACTION ISOLATION LEVELは、アプリケーションがConnection.getTransactionIsolation（）を呼び出すたびに実行され、C3P0は接続を作成するたびにgetTransactionIsolation（）を呼び出します。
接続プールが多数の接続を作成および破棄している場合、PgJDBCドライバーはgetTransactionIsolation（）を呼び出すたびにクエリを実行するため、データベースに対してSHOW TRANSACTION ISOLATION LEVELのクエリが多数発生することになります。
私は同じ問題を見ました。より高いpostgresバージョンを使用しているときに発生したようです。 postgresドライバー42.2.6をアップグレードして修正しました。