0044213: Reduce lock in Batch Of Tasks generator to Warehouse Level

Notes
(0120358) hgbot (developer) 2020-05-27 13:08	Repository: erp/pmods/org.openbravo.warehouse.advancedwarehouseoperations Changeset: 71bcedb2b5213f327afd3d0031d9bfb4f916ec15 Author: Víctor Martínez Romanos <victor.martinez <at> openbravo.com> Date: Wed May 27 09:52:20 2020 +0200 URL: http://code.openbravo.com/erp/pmods/org.openbravo.warehouse.advancedwarehouseoperations/rev/71bcedb2b5213f327afd3d0031d9bfb4f916ec15 [^] Fixes ISSUE-44213: Task generation: lock by warehouse The AWO task generator was running as a singleton, ie only one task generation instance could be run at the same time in the Openbravo instance. This implementation was done at the beginning of the process, just when the Batch of Tasks document was created (specifically when the doc's sequence was consumed). Although the lock is necessary, it is too aggressive and the scope can be reduced. In this patch we reduce the lock to warehouse level, so several warehouses can run the task generation in parallel (one task generation per warehouse). From one side we move the assignation of the Batch of Task document sequence to the last steps in the process, so the global lock time is reduced to the very minimum. From another side, just after all the task requirements have been generated, we try to calculate the tasks for each task requirement. In that exact moment we lock the task requirement's warehouse. Note that the task requirements are consumed ordered by warehouse, so we avoid dead locks if two parallel task generators are trying to work with the same warehouses. The lock mechanism is inteligent, in the sense that it only tries to lock warehouses not previously locked (usually all the task requirements belong to the same warehouse, so only 1 lock should be necessary in that case). The warehouse lock is done in database (not in Java/Hibernate) so the patch is safe in a cluster environment. For that we use the OBDal.getObjectLockForNoKeyUpdate() method, that finally creates a Write lock in DB. So with this patch we have two clear improvements: 1. Several warehouses can generate tasks at the same time. So the more warehouses the instance has, the better improvement. 2. The (warehouse) lock is delayed to the moment were the tasks are going to be really calculated. All the previous logic related to the task requirements generation is out of the lock, so the lock time is also reduced. Although this topic is very sensitive, the risk with this patch is very low. --- M src/org/openbravo/warehouse/advancedwarehouseoperations/centralbroker/BatchOfTasksGenerator.java M src/org/openbravo/warehouse/advancedwarehouseoperations/centralbroker/InventoryTransactionTypeAlgorithm.java M src/org/openbravo/warehouse/advancedwarehouseoperations/task/TasksGenerator.java ---

(0120359) dmiguelez (viewer) 2020-05-27 13:11	At the same time, create a purchase order reception in one Warehouse and a different Purchase Order reception in a different Warehouse, the system should allow to do so.

(0120360) dmiguelez (viewer) 2020-05-27 13:12	Code Review + Testing Ok

Issue History
Date Modified	Username	Field	Change
2020-05-27 13:06	dmiguelez	New Issue
2020-05-27 13:06	dmiguelez	Assigned To	=> dmiguelez
2020-05-27 13:06	dmiguelez	OBNetwork customer	=> No
2020-05-27 13:07	dmiguelez	Relationship added	related to 0039786
2020-05-27 13:08	hgbot	Checkin
2020-05-27 13:08	hgbot	Note Added: 0120358
2020-05-27 13:08	hgbot	Status	new => resolved
2020-05-27 13:08	hgbot	Resolution	open => fixed
2020-05-27 13:08	hgbot	Fixed in SCM revision	=> http://code.openbravo.com/erp/pmods/org.openbravo.warehouse.advancedwarehouseoperations/rev/71bcedb2b5213f327afd3d0031d9bfb4f916ec15 [^]
2020-05-27 13:11	dmiguelez	Note Added: 0120359
2020-05-27 13:12	dmiguelez	Review Assigned To	=> dmiguelez
2020-05-27 13:12	dmiguelez	Note Added: 0120360
2020-05-27 13:12	dmiguelez	Status	resolved => closed
2022-09-06 17:18	caristu	Category	Advance Warehouse Operations => Advanced Warehouse Operations