Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0029611Openbravo ERPA. Platformpublic2015-04-16 16:002022-02-01 08:08
ReporterAugustoMauch 
Assigned ToTriage Platform Base 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusacknowledgedResolutionopen 
PlatformOS5OS Version
Product Version 
Target VersionFixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customerOBPS
Web browser
ModulesCore
Support ticket36202
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0029611: The way we disable triggers with TriggerHandler may lead to leaving the triggers disabled indefinitly
DescriptionIf for whatever reason TriggerHandler.getInstance().disable() is invoked, but the transaction is commited before executing TriggerHandler.getInstance().enable(), the database triggers would be left disabled.

In that case, a row would be committed to the AD_SESSION_STATUS table that would prevent the triggers from being executed. This problem would persist until a transaction is commited having executed TriggerHandler.getInstance().enable().
Steps To ReproduceThe following actions lead to leaving the database triggers disabled:
- TriggerHandler.getInstance().disable() is invoked
- For whatever reason (it is missing, or not properly handled in a finally block, etc), TriggerHandler.getInstance().enable() is not invoked
- The DAL transaccion is commited
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
related to defect 0029632 closed tegik_forge Openbravo Localizations Error found in "Adaptación WebPOS para factura electrónica" module 
related to defect 0030174RR15Q3 closed mtaal Retail Modules Triggers temporarily disabled for whole application through webpos 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2015-04-16 16:00AugustoMauchNew Issue
2015-04-16 16:00AugustoMauchAssigned To => platform
2015-04-16 16:00AugustoMauchOBNetwork customer => No
2015-04-16 16:00AugustoMauchModules => Core
2015-04-16 16:00AugustoMauchTriggers an Emergency Pack => No
2015-05-15 10:00AugustoMauchIssue Monitored: alostale
2015-05-15 10:00AugustoMauchReview Assigned To => alostale
2015-05-15 11:01AugustoMauchIssue End Monitor: alostale
2015-05-15 11:01AugustoMauchReview Assigned Toalostale =>
2015-05-15 14:17ngarciaRelationship addedrelated to 0029632
2015-05-15 14:20ngarciaIssue Monitored: ngarcia
2015-05-15 14:21ngarciaOBNetwork customerNo => Yes
2015-05-15 14:21ngarciaSupport ticket => 36202
2015-05-15 14:21ngarciaSeveritymajor => critical
2016-01-26 09:56AugustoMauchRelationship addedrelated to 0030174
2016-01-26 09:57AugustoMauchNote Added: 0083606
2016-01-26 09:57AugustoMauchSeveritycritical => major
2016-01-26 09:59AugustoMauchNote Added: 0083607
2017-06-19 09:29alostaleNote Added: 0097472
2017-06-19 09:29alostaleStatusnew => acknowledged
2022-02-01 08:08alostaleAssigned Toplatform => Triage Platform Base

Notes
(0083606)
AugustoMauch   
2016-01-26 09:57   
Severity downgraded to Major, as the main flow where this happened was fixed in the issue [1]

[1] https://issues.openbravo.com/view.php?id=30174 [^]
(0083607)
AugustoMauch   
2016-01-26 09:59   
Issue [1] prevents the problem from happening when the connection is closed using the SessionHandler.commitAndClose and SessionHandler.commitAndStart methods, but not when the commit method is invoked directly on the connection. This case can probably be covered using the Apache JDBC Connection Pool by implementing an interceptor [2]

[1] https://issues.openbravo.com/view.php?id=30174 [^]
[2] https://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html#Interceptors [^]
(0097472)
alostale   
2017-06-19 09:29   
A simple solution to analyze might be to add a trigger to AD_SESSION_STATUS so that in case trx is committed having triggers disabled, it transparently would reset it.