[SWF-1525] Database connection leak using JPA and loading lazy initialized entities using WebFlow's presistence context Created: 08/Mar/12 Updated: 07/Feb/17
|Project:||Spring Web Flow|
|Component/s:||Integration: Persistence Support|
|Reporter:||Artem Karpenko||Assignee:||Rossen Stoyanchev|
|Labels:||hibernate, jpa, waiting-for-triage|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
When entities have lazy-initialized relations and they are loaded using WebFlow's persistence context (without transaction) then database connection is not closed but at the same time is not reused later - i.e. it's just lost. This problem initially appeared in working project and I was able to reproduce it in small test project (attached).
How to reproduce problem.
This issue is basically the same as
|Comment by Artem Karpenko [ 08/Mar/12 ]|
Having read about your GitHub-based system for demo projects just now I've added one: no JSF, based on SWF-0000.
|Comment by Rossen Stoyanchev [ 08/Mar/12 ]|
Thanks for providing the sample code. I've modified the project slightly to use HSQLDB.
|Comment by Fabricio Colombo [ 17/Apr/12 ]|
We have the same issue and this appear does not be a spring bug, but a hibernate behaviour how related at https://hibernate.onjira.com/browse/HHH-4808
Using spring webflow, we implemented a workaround to force closing connections using a FlowExecutionListener.
Here is the code:
If anyone has another solution, please, let us know.
|Comment by Artem Karpenko [ 03/May/12 ]|
thank you for confirmation and for proposed solution. Interesting enough, our project also had a somewhat similar workaround targeting paused method:
This was introduced far before I joined our project and seemed to be good enough. Nevertheless we experienced rare cases of choking of application with connection pool being exhausted. Your suggestion made me retest our application and repro-sample once more and I discovered something new. The main thing - that we were using 2.2.1 in production while 2.3.0 fixed some problems related to handling of persistence with subflows; these problems caused additional chaos in my understanding of problem. So I rechecked with 2.3.1 and it appears that your solution (and ours as well) fixes connection leaks in our application.
However I found another case where connections are still leaked. This is not from our real application but I'd post this here so that you would be aware of existing deficiency in presented approach with paused method. You can check out example at https://github.com/artem-karpenko/spring-webflow-issues. I've modified slightly sample project that was added here as repro-project - added extended JPA flow listener, simple subflow configuration and appropriate JSP view. The main point in this case - database connection is leaked (even when using "fixed" listener) when loading of lazy-initialized entities is done using WebFlow's persistence context and this loading is performed during the transition to subflow that does not have <persistence-context /> configured. Rather specific case, I admit
That being said, I myself will probably be satisfied with our "solution" but it'd be nice if this problem would however be addressed because it makes out-of-the-box integration with Hibernate (other JPA providers too?) and any connection pool practically unusable.
|Comment by Fabricio Colombo [ 04/May/12 ]|
a few days ago we found a very bad side effect with our approach, when the "transactionTemplate.execute" is executed, the transaction is committed before the flow endstate to be achieved.
Since then, we leave aside the problem, and yesterday we started to solve the problem, and our new approach is very similiar.
I agree with you, the approach using session.disconnect() seems good enough.
|Comment by guido moscarella [ 31/Jul/12 ]|
I had the same problem, but setting hibernate.connection.release_mode to after_transaction seems to have fixed it. The connection release mode was set to on_close by default.
|Comment by pas filip [ 07/Feb/17 ]|
Hi, I worked recently on an application that was leaking connections and that was using Webflow + JSF + JPA (1.2).
The solution we implemented extends Spring jpa flow listener and seems to be working fine so far: