在使用Postgres和Hibernate（Grails）的select語句之後的空閒事務

Question

我正在使用連接到Postgres的Grails 1.3.7 8.4 我們正在對我們的應用程序進行一些功能測試，並遇到問題。 幾分鐘後，我們對數據庫的所有連接都處於事務中，並且請求超時。 我試着確定使用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，並且我發現它們都具有與最後一個執行相同的最後一條語句。他們中的大多數有不同的ID，很少有相同的，但他們在不同的時刻執行，所以我懷疑這是根本原因。

我也檢查了Tomcat上的日誌。沒有什麼特別的。最後做的事情是hibernate查詢，然後沒有別的。

我已經檢查了連接池設置，它在發佈後以及閒置時檢查連接，以確保連接正常。

我重新啓動了tomcat並再次運行測試。幾分鐘後，我結束了與交易中的所有IDLE連接。這次不同的查詢，我再也不會考慮奇怪了。只是一個簡單的選擇語句。

所以..現在是問題的一部分。 有什麼明顯的我失蹤了？一些簡單的修復，我可以申請，設置或什麼... 我不知道我應該去現在這個，我應該採取什麼來解決它。編號： 要清楚的事情。這是一個在tomcat上部署的grails應用程序。我們將控制器操作用作「REST like」端點。集成和單元測試運行良好。我們目前正在使用Soapui和5個線程運行一個簡單的場景來進行功能測試，以模擬用戶的行爲。

Answer 1

好的..所以經過2天的痛苦，我們設法弄清了這件事情。 看來，使用HSQLDB時，我們的設置太有限，無法找到它，這就是爲什麼它只發生在Postgres下。 問題在於Spring配置了bean池。我不確定它有什麼問題，因爲它是一個簡單的配置，基本上從Spring文檔複製粘貼&，但是在更改代碼以使對象繞過池之後，一切似乎都很好。