Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue Details[ Jump to Notes ] [ Issue History ] [ Print ]
ID
0027638
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Retail Modules] Cash upcriticalalways2014-09-18 16:522014-10-02 19:02
ReporteregoitzView Statuspublic 
Assigned Tomarvintm 
PriorityimmediateResolutionfixedFixed in VersionRR14Q4
StatusclosedFix in branchpiFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Merge Request Status
Review Assigned Tomarvintm
OBNetwork customerOBPS
Support ticket31173
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0027638: The cashup process takes long in some cases and causes locks on the database

DescriptionThe cashup process takes long in some cases and causes locks on the database.
If many cashups are done at the same time and the first one takes long, a lock is made on the ad_sequence table to obtain the documentno for the shipment.
The rest of casuhps are locked until the first one finish.
It causes locks and performance problems on the server.
Steps To Reproduce-Execute several cashups at the same time and check the pg_locks table of postgresql.
TagsPerformance
Attached Files

- Relationships [ Relation Graph ] [ Dependency Graph ]
related to defect 0027943 closedmtaal The OrderLoader process produce locks on the ad_sequence table. 

-  Notes
(0070443)
hgbot (developer)
2014-09-26 18:02

 Repository: erp/pmods/org.openbravo.retail.posterminal
Changeset: 8182ad32c31917bd711e53fc24da1aead418a474
Author: Martin Taal <martin.taal <at> openbravo.com>
Date: Fri Sep 26 17:05:44 2014 +0200
URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/8182ad32c31917bd711e53fc24da1aead418a474 [^]

Related to issue 27638: The cashup process takes long in some cases and causes locks on the database
Made executeHooks method protected to allow testcase to extend it.

---
M src/org/openbravo/retail/posterminal/CashCloseProcessor.java
---
(0070444)
hgbot (developer)
2014-09-26 18:02

 Repository: erp/pmods/org.openbravo.retail.posterminal
Changeset: 7f7810cdeba3b757e8e85ecfeb123b700bb80882
Author: Martin Taal <martin.taal <at> openbravo.com>
Date: Fri Sep 26 17:07:27 2014 +0200
URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/7f7810cdeba3b757e8e85ecfeb123b700bb80882 [^]

Related to issue 27638: The cashup process takes long in some cases and causes locks on the database
- Let the flush happen just before enabling the triggers
- change the log level from info to debug
- made executeHooks protected to make it extendable (for unit testcases)

---
M src/org/openbravo/retail/posterminal/OrderLoader.java
---
(0070445)
hgbot (developer)
2014-09-26 18:02

 Repository: erp/pmods/org.openbravo.retail.posterminal
Changeset: bb9887a055cd64ae0bd2880faced99746454e15a
Author: Martin Taal <martin.taal <at> openbravo.com>
Date: Fri Sep 26 17:09:51 2014 +0200
URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/bb9887a055cd64ae0bd2880faced99746454e15a [^]

Related to issue 27638: The cashup process takes long in some cases and causes locks on the database
- placed flush at one location
- implemented getCashCloseProcessor method to make retrieving cash close processor extendable
- moved cashUp.setProcessedbo to cash close processor as it should be there at the end
- saving the cashup is not needed as the cashup is already retrieved from hibernate, saving happens automatically

---
M src/org/openbravo/retail/posterminal/ProcessCashClose.java
---
(0070446)
hgbot (developer)
2014-09-26 18:02

 Repository: erp/pmods/org.openbravo.retail.posterminal
Changeset: 7665b2eaa8ccf2e71c4eae5d73b5653965ad4d05
Author: Martin Taal <martin.taal <at> openbravo.com>
Date: Fri Sep 26 17:50:12 2014 +0200
URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/7665b2eaa8ccf2e71c4eae5d73b5653965ad4d05 [^]

Related to issue 27638: The cashup process takes long in some cases and causes locks on the database
- Only keep one flush action, is enough also for larger cashups
- Removed intermediate session clear, cashups are large enough to use clear, also gives clearer/less complex structure
- Read shipments directly from orderline, instead of using separate queries, prevents a query in the database
- Refresh of object from db not needed, adding invoiceline to orderline in the code, this works also

---
M src/org/openbravo/retail/posterminal/OrderGroupingProcessor.java
---
(0070447)
hgbot (developer)
2014-09-26 18:03

 Repository: erp/pmods/org.openbravo.retail.posterminal
Changeset: 7b650d0dfbd4ba968a1fcd1af3e27c93652f10be
Author: Martin Taal <martin.taal <at> openbravo.com>
Date: Fri Sep 26 17:56:05 2014 +0200
URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/7b650d0dfbd4ba968a1fcd1af3e27c93652f10be [^]

Related to issue 27638: The cashup process takes long in some cases and causes locks on the database
Added testcase to test performance of cashup and orderloading

---
M src/org/openbravo/retail/posterminal/OrderGroupingProcessor.java
A src-test/org/openbravo/retail/posterminal/OBBaseRetailTest.java
A src-test/org/openbravo/retail/posterminal/POSOrderCashupPerformanceTest.java
A src-test/org/openbravo/retail/posterminal/cashup.json
A src-test/org/openbravo/retail/posterminal/order1.json
A src-test/org/openbravo/retail/posterminal/order2.json
---
(0070448)
hgbot (developer)
2014-09-26 18:09

 Repository: erp/pmods/org.openbravo.retail.posterminal
Changeset: 2d6d69c19e41fc3136bfa669e1045a0338ab0079
Author: Martin Taal <martin.taal <at> openbravo.com>
Date: Fri Sep 26 18:08:06 2014 +0200
URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/2d6d69c19e41fc3136bfa669e1045a0338ab0079 [^]

Related to issue 27638, Backed out changeset 7b650d0dfbd4, files committed together
Files should be committed in separate commits

---
M src/org/openbravo/retail/posterminal/OrderGroupingProcessor.java
R src-test/org/openbravo/retail/posterminal/OBBaseRetailTest.java
R src-test/org/openbravo/retail/posterminal/POSOrderCashupPerformanceTest.java
R src-test/org/openbravo/retail/posterminal/cashup.json
R src-test/org/openbravo/retail/posterminal/order1.json
R src-test/org/openbravo/retail/posterminal/order2.json
---
(0070449)
hgbot (developer)
2014-09-26 18:09

 Repository: erp/pmods/org.openbravo.retail.posterminal
Changeset: 66be68f56a16c01623129680f237bd4925c33ccd
Author: Martin Taal <martin.taal <at> openbravo.com>
Date: Fri Sep 26 18:08:47 2014 +0200
URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/66be68f56a16c01623129680f237bd4925c33ccd [^]

Related to issue 27638, added testcase to test/check performance

---
A src-test/org/openbravo/retail/posterminal/OBBaseRetailTest.java
A src-test/org/openbravo/retail/posterminal/POSOrderCashupPerformanceTest.java
A src-test/org/openbravo/retail/posterminal/cashup.json
A src-test/org/openbravo/retail/posterminal/order1.json
A src-test/org/openbravo/retail/posterminal/order2.json
---
(0070450)
hgbot (developer)
2014-09-26 18:09

 Repository: erp/pmods/org.openbravo.retail.posterminal
Changeset: addb7aa2c08aaa1d660a9b82da4432ef6cb6326a
Author: Martin Taal <martin.taal <at> openbravo.com>
Date: Fri Sep 26 18:09:30 2014 +0200
URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/addb7aa2c08aaa1d660a9b82da4432ef6cb6326a [^]

Related to issue 27638: The cashup process takes long in some cases and causes locks on the database
Set the document no at the end of the ordergrouping in a separate flush, this limits the time the sequence table is locked

---
M src/org/openbravo/retail/posterminal/OrderGroupingProcessor.java
---
(0070456)
mtaal (viewer)
2014-09-26 22:34

 .
(0070457)
mtaal (viewer)
2014-09-26 22:34

 Resolved with above commits

- Issue History
Date Modified Username Field Change
2014-09-18 16:52 egoitz New Issue
2014-09-18 16:52 egoitz Assigned To => marvintm
2014-09-18 16:52 egoitz OBNetwork customer => Yes
2014-09-18 16:52 egoitz Support ticket => 31173
2014-09-18 16:52 egoitz Resolution time => 1411164000
2014-09-18 16:52 egoitz Triggers an Emergency Pack => No
2014-09-18 16:53 egoitz Tag Attached: Performance
2014-09-26 18:02 hgbot Checkin
2014-09-26 18:02 hgbot Note Added: 0070443
2014-09-26 18:02 hgbot Checkin
2014-09-26 18:02 hgbot Note Added: 0070444
2014-09-26 18:02 hgbot Checkin
2014-09-26 18:02 hgbot Note Added: 0070445
2014-09-26 18:02 hgbot Checkin
2014-09-26 18:02 hgbot Note Added: 0070446
2014-09-26 18:03 hgbot Checkin
2014-09-26 18:03 hgbot Note Added: 0070447
2014-09-26 18:09 hgbot Checkin
2014-09-26 18:09 hgbot Note Added: 0070448
2014-09-26 18:09 hgbot Checkin
2014-09-26 18:09 hgbot Note Added: 0070449
2014-09-26 18:09 hgbot Checkin
2014-09-26 18:09 hgbot Note Added: 0070450
2014-09-26 22:34 mtaal Status new => scheduled
2014-09-26 22:34 mtaal Note Added: 0070456
2014-09-26 22:34 mtaal fix_in_branch => pi
2014-09-26 22:34 mtaal Note Added: 0070457
2014-09-26 22:34 mtaal Status scheduled => resolved
2014-09-26 22:34 mtaal Resolution open => fixed
2014-09-30 18:16 jpcalvente Issue Monitored: jpcalvente
2014-10-02 19:02 marvintm Review Assigned To => marvintm
2014-10-02 19:02 marvintm Status resolved => closed
2014-10-02 19:02 marvintm Fixed in Version => RR14Q4
2014-10-22 10:23 egoitz Relationship added related to 0027943

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker