Anonymous | Login
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
TypeCategorySeverityReproducibilityDate SubmittedLast Update
design defect[Modules] Advanced Warehouse Operationsmajorhave not tried2018-12-12 09:292021-11-08 15:05
ReportervmromanosView Statuspublic 
Assigned Tovmromanos 
PrioritynormalResolutionopenFixed in Version
StatusacknowledgedFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Regression date
Regression introduced by commit
Regression level
Review Assigned To
Regression introduced in release

0039786: Too aggressive lock in Batch Of Tasks Generator

DescriptionWhen running the Task Generator a global lock is created to avoid stock/task generation conflicts. See 0039740 note.

Although the lock is necessary, maybe it's too aggressive and the scope can be reduced.

For example, right now if you have many warehouses the lock affects to all of them, regardless you're just generating tasks for one of them. That means that if a task generator is running for warehouse A, a task generation in warehouse B must wait till A is finished, regardless it is very unlikely task generator for B consumes stock/bins in warehouse A (except for a Distribution Order or any other external routing related ITT).

I think the minimum scope for the lock must be in the Routing's IRArea From and IRArea To. When you're generating a task, only the stock and bins within the routing are really affected, and the rest of the warehouse can operate without any lock.
For example, if a picking task is being generated for routing with IRAreas "Storage - Shipping", we just need to lock both areas and leave the rest free so, for example, a purchase order reception can safely take place in the "Receipt" area.

This change will require to lock the IRArea From and IRArea To on each task generation and commit the transaction just after the task (and everything around the task, like reservations or capacity) is being created, so both areas are immediately unlocked for the next task generation (that might lock again the same areas or not) and the stock and bins are already updated for the next run.
Steps To ReproduceAt the same time, create a purchase order reception and a sales order picking. Verify the global lock avoids to run both task generations at the same time. This is not necessary and they can both run at the same time.
Proposed SolutionImplement lock at IRA From and IRA To for the calculated routing.
Commit individually each task generation (and everything around the task, like reservations or capacity).
Verify performance penalty of multiple commits vs a global lock with one commit. Based on the analysis try other lock approaches, like single locking at warehouse.
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]
related to defect 0039740 closedvmromanos Database contention on the BatchOfTasksGenerator class 
related to design defect 0044213 closeddmiguelez Reduce lock in Batch Of Tasks generator to Warehouse Level 

-  Notes
vmromanos (manager)
2021-11-08 15:05

Four possibilities to consider:
- Keep the lock at warehouse level.
- Do not lock: this might work fine in big warehouses with many references and bins
- Lock by Product and Locators To:
  - Lock the product, so no other task can steal the stock
  - Lock the possible locators to only in non-functional areas. Any possible locator to candidate should be locked to avoid problems with capacity mainly, so that's why we propose the lock only for non-functional areas.
- Optimistic lock: do not lock at the beginning of the process, but check at the end of the process if the task generation is fine. It would require a refactor in the task generation to commit each task individually, so it could be very complex.

Maybe adding a configuration to support "Do not lock" and "Lock by Warehouse" (or "Lock by Product and Locators To" if we finally implement it) could be done here.

- Issue History
Date Modified Username Field Change
2018-12-12 09:29 vmromanos New Issue
2018-12-12 09:29 vmromanos Assigned To => Triage Finance
2018-12-12 09:30 vmromanos Relationship added related to 0039740
2018-12-12 09:30 vmromanos Assigned To Triage Finance => vmromanos
2018-12-12 09:30 vmromanos Status new => acknowledged
2018-12-12 09:58 vmromanos Proposed Solution updated
2020-05-27 13:07 dmiguelez Relationship added related to 0044213
2021-11-08 15:05 vmromanos Note Added: 0132893
2022-09-06 17:18 caristu Category Advance Warehouse Operations => Advanced Warehouse Operations

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker