①Is it correct to understand that in the following API processes, record locking (exclusive control) is done when performing stock in/out operations?
・ShopFloorConnector.svc/IssueComponentLine
・ShopOrdersHandling.svc/IssueExecute
・Issue_Inventory_Part_SVC.Do_Issue_Inventory_Part
・Receive_Inventory_Part_SVC.Do_Receive_Inventory_Part_In_Update
②If another in/out process runs at the same time as the API execution, will the process that runs later cause an error?
③In the API, how is data being controlled when it comes to handling stock in and out?
→Since access to inventory data happens frequently, it's hard to imagine that the process executed later would fail every time we access the same record, so I'm curious about what kind of control is in place.
Exclusive control at the API inventory unit level
+1
+1Hi
All four of those APIs end up in the same core inventory logic, so they behave the same way. Here's the short version:
1. Yes, there's record locking. When a stock in/out happens, the specific INVENTORY_PART_IN_STOCK record (that exact part + location + lot/serial + handling unit combination) gets a row lock before the on-hand quantity is updated. It's a normal Oracle SELECT … FOR UPDATE lock, and it's only held until the transaction commits.
2. No, the second process usually won't error. If two processes hit the same stock record, the later one just waits for the first to finish, then continues. It's queued, not rejected. You'd only see an actual error in real conflict cases - for example the quantity isn't enough anymore after the first commits, or a genuine deadlock (ORA-00060), which typically only happens in processes that touch two locations at once (like a Move), not a plain issue or receive.
3. Why frequent access doesn't constantly fail: two reasons.
The lock is only held for the few milliseconds the update runs, so records free up almost instantly.
A normal issue/receive only touches one part + location record, so two processes only collide if they hit the exact same one. Everything else runs in parallel.
When a process does need to touch several records, they're locked in a consistent order (part no, then location no) to keep waits predictable and avoid deadlocks.
So, it's short row locks plus very short transactions - that's why concurrent access queues for a moment instead of erroring out.
Hope that helps!
+1Hi
Thank you for your explanation.
I understand the overall concept, but I would like to confirm whether my understanding below is correct:
Can I assume that this behavior is not limited to the four APIs you reviewed, but is the general inventory control mechanism applied across inventory-related processes?
For example, if an issue transaction from a Manufacturing Order and a receipt transaction from a Purchase Order for the same part are executed at the same time, would the same inventory control and locking behavior you described also apply in that scenario?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.