Hot SKU feature

The Hot SKU feature is enabled by default to help reduce the level of inventory item lock.

If inventory lock contention is still unacceptably high after you have applied the optimization from above, you have two options that can potentially reduce the level of inventory item lock:

  • Hot SKU Feature
  • Hot SKU Feature (without lock request timeout)

Hot SKU feature (without lock request timeout)

In a nutshell, the Hot SKU feature tracks the time to lock inventory item records. If a lock request for an item (called SKUA) is longer than the yfs.hotsku.secondsToClassifyAsAbnormalTime threshold, the Hot SKU feature increments the number of "abnormal" lock attempts for SKUA. If the number of "abnormal" attempts in a monitoring window is more than the yfs.hotsku.secondsToClassifyAsAbnormalTime threshold, the Hot SKU feature considers SKUA a Hot SKU.

In the example below, the first transaction was able to obtain the SKUA lock immediately.
A diagram displaying the transaction obtaining a SKUA lock immediately, displaying time it takes for the transaction to obtain the SKUA lock and be active and the time it takes for a transaction to attempt to obtain a SKUA lock and is blocked.

As a result, the number of abnormal lock attempts (which we assume to have started at zero) stays at zero. The second transaction tries to obtain a SKUA lock and is blocked at first but eventually gets the lock within the abnormal lock time period. Since the request completed within the "abnormal" time, the request was not considered abnormal - as a result, the number of abnormal lock attempts is left at zero and SKUA is not considered a Hot SKU.

The next three transactions try to obtain the lock and were blocked for longer than the abnormal lock time window. Each "abnormal lock" attempt increases the abnormal lock count within that monitoring window. SKUA turns hot when the count reaches the yfs.hotsku.numRequestsInTrackingWindowToKeepAsHotSku threshold (which defaults to 3).

A Hot SKU is downgraded to a normal SKU if the number of references to that SKU is less than the yfs.hotsku.numRequestsInTrackingWindowToKeepAsHotSku threshold in a monitoring window.

Hot SKU detection and enablement occurs at each JVM. For example, a sudden high burst of demand for a single SKU could result in the createOrder adapter to consider that SKU hot. Later, as the downstream agents process those orders, they independently detect and enable those SKUs as Hot SKUs if they encounter sufficient number of "abnormal" locks.

When an inventory item is upgraded to Hot SKU status, transactions do not lock that inventory item before manipulating its demand or supply information. Instead, the transactions insert the demand or supply information into two new tables, YFS_INVENTORY_DEMAND_ADDNL or YFS_INVENTORY_SUPPLY_ADDNL respectively. As a result, demand or supply information can be recorded in a non-blocking manner because inserts do not block other transactions from proceeding. Transactions continue in this mode until the inventory items have been downgraded to the normal status.

Inventory demand queries automatically check both the YFS_INVENTORY_DEMAND and YFS_INVENTORY_DEMAND_ADDNL tables. Similarly, inventory supply queries checks the YFS_INVENTORY_SUPPLY and YFS_INVENTORY_SUPPLY_ADDNL tables.

The quantities in the inventory additional records are consolidated back to their base inventory tables by the Consolidate Additional Inventory agent.

Hot SKU feature with lock request timeout option

The lock request timeout option in the Hot SKU feature may be useful in reducing the amount of lock holding time by limiting the time the lock request blocks later transactions. This can be useful when you are primarily processing large orders (for example, over 50 lines per order) where the transactions could block other transactions for a very long time.

Using the previous example, with the same transaction arrival times and processing times, we see that Transaction 1 immediately obtains SKUA's record lock and processes SKUA without the Hot SKU feature. Transaction 2 comes in and is blocked by Transaction 1 but eventually gets the lock within the abnormal time. As a result, Transaction 2 also processes SKUA without the Hot SKU feature.

A figure displaying multiple transactions and the time it takes each to obtain a SKUA lock while both active and blocked, and the time a transaction processes a SKUA as a Hot SKU.

Transaction 3 starts and is blocked by Transaction 1. Eventually, Transaction 3's lock request times out. When that happens, the transaction increments SKUA's abnormal lock attempt count to 1 and reissues the lock request.

Similarly, Transaction 4 is blocked by Transaction 1 until its lock request times out. This transaction increments the abnormal lock attempt count to 2.

When Transaction 3 times out its second lock request, the Hot SKU feature upgrades SKUA to Hot SKU status. When that has happened, Transaction 3 can process SKUA even though Transaction 2 still has the SKUA record lock.

Similarly, when Transaction 4 times out, it is able to process SKUA.

More importantly, when Transaction 5 comes in, it sees that SKUA is already a Hot SKU and does not attempt to lock the SKUA record.

One important benefit to lock request timeout is in situations where the blocker could be holding on to locks for a long time. With the timeout option enabled, the blocked transactions has to wait up to a maximum of abnormal lock count (yfs.hotsku.numberOfAbnormalLocksForSwitchToHotSKU) times the abnormal lock timeout (yfs.hotsku.secondsToClassifyAsAbnormalTime) before the transaction starts to process the SKU as a Hot SKU.