Have you ever seen a mob at a store fighting for the last 70% off Blu-ray player ? Have you wondered what is like if they were shopping in your e-commerce site instead? In today's post I discuss inventory contention.
In contrast with other tables where each shopper keeps its own data (Orders, Addresses, etc), inventory is shared. While a shopper is updating inventory for a SKU, other shoppers trying to get the same product will need to wait. If the product is popular enough, several shoppers will be waiting to update inventory. The shoppers for that product will notice a lag in response times and, as the number of shoppers trying to check-out increases, the whole site could be impacted.
Diagnosing inventory contention
The most common effect for inventory contention is slow checkout, but depending on the inventory model, add-to-cart could also be impacted. If the problem is severe enough, the WebContainer pool will be taken over by inventory threads rendering the site unusable (but that's a rather extreme scenario).
Javacores collected while the JVMs are experiencing problems will show the delay. This will vary depending on the inventory model. You could, for example, see threads waiting to update an inventory table, or waiting for the inventory back-end system to respond.
The following sample stack shows a thread trying to update the INVENTORY table (non-ATP inventory model) on the OrderProcess command. You can see the findByMultipleCatalogEntryAndFulfillmentCenterAndStoreForUpdate() SELECT FOR UPDATE was executed and the thread is waiting for the database (DB2 in this case) to respond:
at java/net/SocketInputStream.socketRead0(Native Method)
at java/net/SocketInputStream.read(SocketInputStream.java:140(Compiled Code))
at com/ibm/db2/jcc/am/ResultSet.next(ResultSet.java:309(Compiled Code))