0039740: Database contention on the BatchOfTasksGenerator class

Notes
(0108382) vmromanos (viewer) 2018-12-11 11:17	The lock is absolutely necessary at this point and it avoids many possible issues due to concurrency. Removing or relaxing the lock is very dangerous and may corrupt the task generation or stock status. The CentralBroker must act as a Singleton, with only one request running at the same time. The lock at BatchOfTasks sequence is actually the responsible of this. If we allow multiple instances of the batch of tasks generator they can create conflicts between them meanwhile they are running, specially if we implement the proposed solution. Let's see an example if we remove the lock: Imagine we only have 1 unit of "MyProduct" available in the warehouse. No overissue is allowed. Two sales orders (SO-1 and SO-2) have 1 unit of MyProduct in any of their lines. User A launches the picking for SO-1 and user B launches the picking for SO-2 almost at the same time. SO-1 reaches first the task generation for MyProduct, so it creates the task, and continues with the rest of the lines. SO-2 reaches MyProduct line. If we relax the lock as in the proposed solution, the task generation will find also the MyProduct unit and it will create another task, which is wrong because there is only 1 unit in the stock and it has been already associated to SO-1. You could also think in committing the SO-1 task generation so SO-2 wouldn't find the stock. This would imply a performance penalty in each of the tasks commits and it won't really ensure the commit is done just in time. Another lock would be necessary meanwhile the individual task is being generated and committed. So the performance improvement compared with the current global lock at bathoftasks would be very low (if any) and the complexity of the process will drastically increase. Let's continue with the example supposing we implement the individual lock explained above instead of the current global lock. Imagine SO-2 finishes first (for example because it has less lines). The MyProduct task won't be generated, because SO-1 have found it first. Now imagine SO-1 task generation throws an exception, for example due to a configuration error. In this case the AWO general rule is very clear: the whole transaction is rollback. So the task generated for MyProduct will be deleted. At the end no picking task for MyProduct will be created neither for SO-1 nor for SO-2, regardless the product is available in the warehouse. The same example with the current global lock would work fine: If SO-1 is the first one that blocks the task generation, the exception will be thrown, so MyProduct will be available for SO-2. If SO-2 is the first one that blocks the task generation, SO-1 won't find it because the task is already created for SO-2 (regardless the exception that we know it is thrown). Summary: the stock is a unique physical resource, so it must be controlled by a unique Task Generator. That's why the lock is required. The task generation in general is very fast and the lock shouldn't affect too much from a performance POV, specially if compared with the benefits it adds.

(0108389) hgbot (developer) 2018-12-11 14:03	Repository: erp/pmods/org.openbravo.warehouse.advancedwarehouseoperations Changeset: 69bc88d902f94af3a1fdf8e538858483cb7a2842 Author: Víctor Martínez Romanos <victor.martinez <at> openbravo.com> Date: Tue Dec 11 14:02:58 2018 +0100 URL: http://code.openbravo.com/erp/pmods/org.openbravo.warehouse.advancedwarehouseoperations/rev/69bc88d902f94af3a1fdf8e538858483cb7a2842 [^] Related to issue 39740: Added code documentation to clarify behavior --- M src/org/openbravo/warehouse/advancedwarehouseoperations/centralbroker/BatchOfTasksGenerator.java ---

Issue History
Date Modified	Username	Field	Change
2018-12-04 11:33	egoitz	New Issue
2018-12-04 11:33	egoitz	Assigned To	=> Triage Finance
2018-12-04 11:33	egoitz	Resolution time	=> 1545087600
2018-12-04 11:33	egoitz	Support ticket	=> 5992
2018-12-04 11:33	egoitz	OBNetwork customer	=> Gold
2018-12-04 11:56	galderromo	Issue Monitored: galderromo
2018-12-04 12:15	Sandrahuguet	Assigned To	Triage Finance => vmromanos
2018-12-05 08:08	Sandrahuguet	Tag Attached: Performance
2018-12-05 16:02	vmromanos	Status	new => acknowledged
2018-12-11 10:35	vmromanos	Status	acknowledged => scheduled
2018-12-11 11:17	vmromanos	Review Assigned To	=> vmromanos
2018-12-11 11:17	vmromanos	Note Added: 0108382
2018-12-11 11:17	vmromanos	Status	scheduled => closed
2018-12-11 11:17	vmromanos	Resolution	open => invalid
2018-12-11 14:03	hgbot	Checkin
2018-12-11 14:03	hgbot	Note Added: 0108389
2018-12-12 09:30	vmromanos	Relationship added	related to 0039786
2022-09-06 17:18	caristu	Category	Advance Warehouse Operations => Advanced Warehouse Operations