java - 使用 Postgres 和 Hibernate(Grails) 选择语句后在事务中空闲

Question

我正在使用连接到 Postgres 8.4 的 Grails 1.3.7我们正在运行我们的应用程序的一些功能测试，我们遇到了一个问题。几分钟后，我们与数据库的所有连接都处于事务中并且请求超时。我尝试使用来自 Ghostwritten Insomnia 的查询来确定发生了什么我得到的只是一些独占锁和访问共享锁。根据Postgres Docs他们一起工作，应该没有什么特别之处。好吧，除了在我重新启动 Tomcat 或终止连接之前它们一直存在之外，没有什么特别的。我已启用日志记录并尝试按照 Depesz 在 his blog 上的描述对其进行分析但我没有发现长期运行的声明。我能够确定事务中空闲的连接的最后语句，这是一个简单的选择，更重要的是 - 它完成得很好 [至少日志是这样说的]。

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 的日志文件，寻找 ID 为 17935 的其他查询，但没有发现任何可疑的东西。并且在与此查询相同[或相似]的时间没有任何内容。

我已经检查了所有 IDLE In Transaction 连接，我发现它们都执行了与上一个相同的最后一个语句。他们中的大多数有不同的 ID，很少有相同的，但他们是在一个非常不同的时刻被执行的，所以我怀疑这是根本原因。

我还检查了 Tomcat 上的日志。那里没什么特别的。最后做的是 hibernate 查询，然后没有别的。

我检查了连接池设置，它会在释放后和空闲时检查连接，以确保连接正常。

我已经重启了 tomcat 并再次运行测试。几分钟后，我结束了事务中的所有连接 IDLE。这次是不同的查询，再一次我认为没有什么奇怪的。只是一个简单的选择语句。

所以.. 现在是问题部分。有什么明显的我想念的吗？我可以应用一些简单的修复，设置或其他东西......我不确定我现在应该去哪里，我应该采取什么下一步来解决它。

编辑:把事情说清楚。这是部署在 tomcat 上的 grails 应用程序。我们将 Controller 操作用作“类似 REST”的端点。集成和单元测试运行良好。我们目前正在使用 Soapui 和 5 个线程运行一个简单的场景来模拟用户行为，从而进行功能测试。

Answer 1

好的.. 经过 2 天的痛苦之后，我们设法解决了这个问题。似乎在使用 HSQLDB 时我们的设置太有限而无法找到它，这就是为什么它只发生在 Postgres 下。问题出在 Spring 配置的 bean 池中。我不确定它有什么问题，因为它是一个简单的配置，基本上是从 spring 文档中复制和粘贴，但是在更改代码以使对象绕过池之后，一切似乎都很好。