私はGrails 1.3.7をPostgres 8.4に接続しています 私たちはアプリケーションの機能テストを行っており、問題が発生しました。 数分後、データベースとの接続はすべてIn Transactionであり、要求はタイムアウトしています。 私はGhostwritten Insomniaのクエリを使って何が起こっているのかを調べようとしましたが、私が得たのはいくつかの排他ロックとアクセス共有ロックでした。 Postgres Docsによれば、彼らは一緒に働き、彼らについて何も特別なものでなければならない。私がTomcatを再起動するか、接続を切断するまでは、何も特別なことはありません。 私はログを有効にして、のDepeszに記述されているようにログを解析しようとしましたが、長時間の実行中のステートメントは見つかりませんでした。私は、トランザクションでIdleであるコネクションの最後のステートメントを判断することができました。それは単純なセレクションでした。アイドルIn PostgresとHibernate（Grails）を使用したselectステートメントで
2012-01-03 21:02:57.397 CET [email protected] 4294 127.0.0.1(34282) LOG: duration: 0.111 ms parse <unnamed>: select questdefin0_.id as id23_0_, questdefin0_.version as version23_0_, questdefin0_.cev_from as cev3_23_0_, questdefin0_.cev_to as cev4_23_0_, questdefin0_.description as descript5_23_0_, questdefin0_.duration as duration23_0_, questdefin0_.level_from as level7_23_0_, questdefin0_.level_to as level8_23_0_, questdefin0_.name as name23_0_, questdefin0_.pack_id as pack10_23_0_, questdefin0_.type as type23_0_, questdefin0_.travel_zone_id as travel13_23_0_, questdefin0_.class as class23_0_ from quest_definition questdefin0_ where questdefin0_.id=$1
2012-01-03 21:02:57.397 CET [email protected] 4294 127.0.0.1(34282) LOG: duration: 0.095 ms bind <unnamed>: select questdefin0_.id as id23_0_, questdefin0_.version as version23_0_, questdefin0_.cev_from as cev3_23_0_, questdefin0_.cev_to as cev4_23_0_, questdefin0_.description as descript5_23_0_, questdefin0_.duration as duration23_0_, questdefin0_.level_from as level7_23_0_, questdefin0_.level_to as level8_23_0_, questdefin0_.name as name23_0_, questdefin0_.pack_id as pack10_23_0_, questdefin0_.type as type23_0_, questdefin0_.travel_zone_id as travel13_23_0_, questdefin0_.class as class23_0_ from quest_definition questdefin0_ where questdefin0_.id=$1
2012-01-03 21:02:57.397 CET [email protected] 4294 127.0.0.1(34282) DETAIL: parameters: $1 = '17935'
2012-01-03 21:02:57.397 CET [email protected] 4294 127.0.0.1(34282) LOG: execute <unnamed>: select questdefin0_.id as id23_0_, questdefin0_.version as version23_0_, questdefin0_.cev_from as cev3_23_0_, questdefin0_.cev_to as cev4_23_0_, questdefin0_.description as descript5_23_0_, questdefin0_.duration as duration23_0_, questdefin0_.level_from as level7_23_0_, questdefin0_.level_to as level8_23_0_, questdefin0_.name as name23_0_, questdefin0_.pack_id as pack10_23_0_, questdefin0_.type as type23_0_, questdefin0_.travel_zone_id as travel13_23_0_, questdefin0_.class as class23_0_ from quest_definition questdefin0_ where questdefin0_.id=$1
2012-01-03 21:02:57.397 CET [email protected] 4294 127.0.0.1(34282) DETAIL: parameters: $1 = '17935'
2012-01-03 21:02:57.397 CET [email protected] 4294 127.0.0.1(34282) LOG: duration: 0.052 ms
私はID 17935の他のクエリを探しているpostgresのログファイルを調べましたが、疑わしいものは見つかりませんでした。このクエリと同じ[または類似の]時間には何も表示されません。
私はすべてのIDLE In Transaction接続をチェックしましたが、最後のステートメントと同じステートメントがすべて実行されていました。彼らのほとんどはIDが異なり、同じものはほとんどありませんでしたが、それらは非常に異なる瞬間に実行されたので、これが根本的な原因ではないかと考えています。
また、Tomcatのログもチェックしました。特別なものはありません。最後に行われるのは、ハイバネートクエリです。
接続プールの設定を確認した後、リリース後に接続がチェックされ、アイドル状態のときに接続が正常であることが確認されます。
私はtomcatを再起動してテストを再実行しました。数分後、私はすべての接続IDLEをトランザクションで終了しました。今回は別のクエリ、私は奇妙とは思わない何も。単なる単純なselectステートメントです。
だから今質問部分。 わからないことがありますか？私が適用することができる簡単な修正、設定、または何か... 私はこれでどこに行くべきか、私はそれを解決するために取るべき次のステップは何であるか分からない。
編集： 明確にする。これはtomcatにデプロイされたgrailsアプリです。私たちはコントローラのアクションを "RESTのような"エンドポイントとして使用しています。統合と単体テストは正常に動作します。 Soapuiと簡単なシナリオを実行している5つのスレッドを使用して、ユーザーの動作をシミュレートして、現時点で機能テストを行っています。
接続がプールに返されたときに 'rollback'を実行するように接続プールを設定できますか？ SELECTステートメントからの暗黙のトランザクション（トランザクションのIDLEを引き起こす）を終了する必要があります。 –
接続はプールに戻されません。要求はクライアントのタイムアウトです。私は使用する接続がもうなくなったらテストを終える。 – Krystian
そして、トランザクションの中でテストの中に 'rollback'を明示的に記述する必要があります。 –