|
|
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. |
|