Notes |
|
(0072194)
|
NaroaIriarte
|
2014-12-01 13:48
(edited on: 2014-12-01 14:09) |
|
-An exception has been forced to watch if it is true that connection leak exists in case of error. But it seems not to occur.
For testing this, the first step is to throw an exception to force to execute the code of the exceptions. The second step is to log in and end session as many times as wanted and after this, the last step, making a postgres query to look the connexions. After this test it seems not to exist any connection leak.
Anyway the releaseRollbackConnection has been added to the code, because it seems to be better this way.
|
|
|
|
Some tests have been performed:
-Firstly, an exception has been thrown for forcing to execute the new added code for exceptions. The code is reached correctly so it works as expected.
-A postgres query has been launched to check the connections to the data base. |
|
|
(0072257)
|
hgbot
|
2014-12-03 09:21
|
|
Repository: erp/devel/pi
Changeset: 1643c8fecb96f82ac652260a49cffdf21f497320
Author: Naroa Iriarte <naroa.iriarte <at> openbravo.com>
Date: Mon Dec 01 15:22:06 2014 +0100
URL: http://code.openbravo.com/erp/devel/pi/rev/1643c8fecb96f82ac652260a49cffdf21f497320 [^]
Fixed issue 27877: No rollback is called in connection error catch.
It seemed to be possible to have a connection leak caused in the "UsageAudit.java" class.
That was because at the final function of this class in a try catch block there was no rollback done.
After some tests it seems not to be any connection leak even without the rollback. But the proper code
to make the rollback has been created, because it seems to be better that way.
For developing this, a new method has been created "releaseConnection". This method is called in the three
try catch blocks of the method "auditActionNoDal".
Now, if one of those excepcions are reached, a rollback will be done.
---
M src/org/openbravo/erpCommon/security/UsageAudit.java
---
|
|
|
|
code reviewed
tested forcing execption in the code. Note before the fix is applied, the problem was not "only" leaked connections; if the exception occurred after the insert, uncommited transactions trying to insert elements in ad_session_usage_audit were kept forever; they could cause locks in ad_session due to FK resulting in completely stalling the whole session. |
|
|
|
|