Question

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

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应用程序。我们将控制器操作用作“REST like”端点。集成和单元测试运行良好。我们目前正在使用Soapui和5个运行简单场景的线程进行功能测试，模拟用户行为。

Answer 1

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

使用Postgres和Hibernate（Grails）在select语句之后进行事务处理

1 个答案: