|View Issue Details|
|Type||Category||Severity||Reproducibility||Date Submitted||Last Update|
|defect||[Openbravo ERP] A. Platform||major||have not tried||2014-10-15 14:41||2015-05-21 09:26|
|Priority||urgent||Resolution||fixed||Fixed in Version||3.0PR15Q1|
|Status||closed||Fix in branch||Fixed in SCM revision||205fdc530e40|
|OS Version||Database version||Ant version|
|Product Version||SCM revision|
|Review Assigned To||AugustoMauch|
|Regression introduced in release|
|Regression introduced by commit|
|Triggers an Emergency Pack||No|
0027878: Code in DalConnectionprovider relate to getTransactionConnection seems to leak db connections always
|Description||The DalConnectionProvider is a wrapper to implement the standard ConnectionProviderInterface but using dal to manage the connections.|
In that interface are 3 related methods
1.) getTransactionConnection to get a new separate connection with auto commit disabled
2.) releaseCommitConnection. To commit & close a aconnection as obtained by 1.)
3.) releaseRollBackConnection. to rollback & close a connection as obtained by 1.)
Reading that code it seems that both 2+3 are implemented wrongly as they do not close the connection.
Problem was stopped while trying to debug the a very bad connection leak seen after this commit:
|Steps To Reproduce||-|
Author: Antonio Moreno <antonio.moreno <at> openbravo.com>
Date: Tue Oct 28 16:14:40 2014 +0100
URL: http://code.openbravo.com/erp/devel/pi/rev/205fdc530e408b51a16a4d596c639339c607af95 [^]
Fixed issue 27878. Changed DalConnectionProvider so that it won't leak connections when using a transaction connection:
> - Now getTransactionConnection won't create a new StatelessSession every time it is called, because this created a new connection pool, and connections for this pool weren't reused. Instead, now the Hibernate ConnectionProvider in the DalSessionFactory is exposed, and used, to get a valid connection which belongs to the right pool.
- Additionally, now the connections are actually closed when the releaseCommitConnection or the releaseRollbackConnection methods are used.
After the changes, we have verified that:
- Connections are not leaked (an infinite loop doesn't reach the maximum number of connections in the database).
- The connection objects are different every time the getTransactionConnection method is called.
- If two transaction connections are created, and an operation is done in the first one, the second one doesn't see the results of it unless a commit is done in the first one.
Code reviewed and verified in pi@38080222ded6.
I have tested this fix with an external connection pool  and it worked fine.
 http://wiki.openbravo.com/wiki/How_to_Use_an_External_Connection_Pool [^]
A changeset related to this issue has been promoted main and to the
Central Repository, after passing a series of tests.
Promotion changeset: https://code.openbravo.com/erp/devel/main/rev/6525fe229e06 [^]
Maturity status: Test
|2014-10-15 14:41||shuehner||New Issue|
|2014-10-15 14:41||shuehner||Assigned To||=> AugustoMauch|
|2014-10-15 14:41||shuehner||Modules||=> Core|
|2014-10-15 14:41||shuehner||Triggers an Emergency Pack||=> No|
|2014-10-15 14:41||shuehner||Relationship added||related to 0027877|
|2014-10-28 16:06||marvintm||Assigned To||AugustoMauch => marvintm|
|2014-10-28 16:07||marvintm||Review Assigned To||=> alostale|
|2014-10-28 16:15||hgbot||Note Added: 0071230|
|2014-10-28 16:15||hgbot||Status||new => resolved|
|2014-10-28 16:15||hgbot||Resolution||open => fixed|
|2014-10-28 16:15||hgbot||Fixed in SCM revision||=> http://code.openbravo.com/erp/devel/pi/rev/205fdc530e408b51a16a4d596c639339c607af95 [^]|
|2014-10-28 16:16||marvintm||Note Added: 0071231|
|2014-10-30 13:03||AugustoMauch||Review Assigned To||alostale => AugustoMauch|
|2014-10-30 13:03||AugustoMauch||Note Added: 0071268|
|2014-10-30 13:03||AugustoMauch||Status||resolved => closed|
|2014-10-30 13:03||AugustoMauch||Fixed in Version||=> 3.0PR15Q1|
|2014-12-30 23:23||hudsonbot||Note Added: 0072998|
|2015-05-15 13:11||alostale||Relationship added||related to 0020580|
|2015-05-21 08:40||alostale||Relationship added||causes 0029902|
|2015-05-21 09:26||alostale||Tag Attached: Performance|
|2016-07-05 16:40||alostale||Relationship added||related to 0033429|
|2016-07-06 10:14||alostale||Relationship deleted||related to 0033429|
|2016-07-06 10:15||alostale||Relationship added||related to 0033438|
|Copyright © 2000 - 2009 MantisBT Group|