Idle In транзакции после оператора select с использованием Postgres и Hibernate (Grails)

Question

Я использую Grails 1.3.7, подключенный к Postgres 8.4 Мы выполняем некоторые функциональные тесты нашего приложения и столкнулись с проблемой. Через несколько минут все соединения, которые у нас есть с базой данных, находятся в состоянии транзакции, и запросы истекают. Я попытался определить, что происходит, используя запрос из Ghostwritten Insomnia , и все, что я получил, это некоторые эксклюзивные блокировки и блокировки общего доступа. Согласно Postgres Docs они работают вместе, и в них не должно быть ничего особенного. Ничего особенного, кроме того, что они остаются, пока я не перезапущу Tomcat или не уничтожу соединения. Я включил ведение журнала и попытался проанализировать их, как описано Депесом на его блоге , но я не нашел давно работающих утверждений. Я был в состоянии определить последние операторы соединений, которые простаивают в транзакции, и это был простой выбор, более того - он был закончен нормально [по крайней мере, так говорят логи].

2012-01-03 21:02:57.397 CET ogsuser@ogs 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 ogsuser@ogs 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 ogsuser@ogs 4294 127.0.0.1(34282) DETAIL:  parameters: $1 = '17935'
2012-01-03 21:02:57.397 CET ogsuser@ogs 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 ogsuser@ogs 4294 127.0.0.1(34282) DETAIL:  parameters: $1 = '17935'
2012-01-03 21:02:57.397 CET ogsuser@ogs 4294 127.0.0.1(34282) LOG:  duration: 0.052 ms

Я просмотрел журналы postgres в поисках других запросов с идентификатором 17935, но не нашел ничего подозрительного. И ничего в то же время [или подобное], что и этот запрос.

Я проверил все соединения IDLE In Transaction и обнаружил, что все они выполняли один и тот же последний оператор, как и последний. У большинства из них были разные идентификаторы, у немногих были одинаковые, но они были выполнены в совершенно другой момент, поэтому я сомневаюсь, что это является основной причиной.

Я также проверил логи Tomcat. Ничего особенного там нет. Последнее, что нужно сделать, это запрос гибернации, а затем ничего больше.

Я проверил настройки пула соединений, он проверяет соединение после освобождения и в режиме ожидания, чтобы убедиться, что соединения в порядке.

Я перезапустил tomcat и снова запустил тест. Через несколько минут у меня закончились все соединения IDLE в транзакции. На этот раз разные запросы, опять же, ничего, что я бы посчитал странным. Просто простое утверждение select.

Итак ... теперь часть вопроса. Есть ли что-то очевидное, чего мне не хватает? Некоторое простое исправление, которое я мог бы применить, настройки или что-то ... Я не уверен, куда мне теперь идти с этим, каков следующий шаг, который я должен сделать, чтобы решить это.

EDIT: Чтобы все было понятно. Это приложение Grails, развернутое на Tomcat. Мы используем действия контроллера как конечные точки типа «REST». Интеграция и модульные тесты работают нормально. В настоящее время мы проводим функциональные тесты с использованием Soapui и 5 потоков, выполняющих простой сценарий, имитирующий поведение пользователя.

Answer 1

Ладно ... так что после 2 дней мучений нам удалось разобраться с этим.Кажется, что при использовании HSQLDB наши настройки были слишком ограничены, чтобы найти это, поэтому это происходило только под Postgres.Проблема была с пулами бобов, настроенными весной.Я не уверен, что с ним не так, поскольку это простая конфигурация, в основном копирование и вставка из документации Spring, но после изменения кода, чтобы получить обход объекта, пул все выглядит нормально.