使用Postgres和Hibernate(Grails)的select语句后在事务中处于空闲状态

2020年11月30日 82点热度 0条评论

我正在使用连接到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,少数具有相同的ID,但是它们在不同的时刻执行,因此我怀疑这是根本原因。

我还检查了Tomcat上的日志。没什么特别的。最后要做的是休眠查询,然后再执行其他操作。

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

我重新启动了tomcat并再次运行测试。几分钟后,我结束了所有连接IDLE的交易。这次不同的查询,再也没有什么我认为很奇怪的。只是一个简单的选择语句。

所以..现在的问题部分。

有什么明显的我想念的吗?我可以套用一些简单的方法,设置或其他方法...

我不确定现在该去哪里,下一步应该解决什么。

编辑:

弄清楚。这是部署在tomcat上的grails应用程序。我们将 Controller Action 用作“REST like”端点。集成和单元测试运行良好。目前,我们正在使用Soapui和5个运行简单场景的线程来进行功能测试,以模拟用户行为。

解决方案如下:

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