Why does Item Based Allocation (IBA) cause blocking locks in the database?

Answer

IBA (for more information on IBA, refer to the Distributed Order Management Guide) by functional definition, locks a particular Order before it creates Order Line Reservations for it.

In some customer implementations, one can see the IBA agent causing heavy database blockages. This occurs when the IBA agent runs at the same time as some of the other Order entity related agents (e.g., Schedule/Release Order, Payment Agents, and Monitors).

If there are items, spread across multiple orders, then the IBA agent will acquire a lock on all those orders that contain these items if they qualify for IBA.
E.g., Suppose there is an extensively ordered item (Item1). On a given day, the system receives 1000 Orders for this Item1. If Item1 qualifies for IBA, then the IBA agent will acquire a lock on all those 1000 orders (in the same transaction boundary). This renders Item1 unavailable to any other agent/API until the IBA agent commits. This causes severe database blockage.

If, in the customer’s implementation, one notices a Hot SKU Item (same Item spread across a large set of Orders) vigorously using IBA, then, based on the business requirement:

   
1.    

   Consider running the IBA agent at non-peak hours or in such a way that it does not conflict with the other Order-related Agents/APIs.

      
   
2.    

   In addition, re-visit the Item configuration (for the particular Item which is HOT) and consider disabling IBA at the Item level (Refer to the Product Management Guide).