What are these tables for: PartBinDeferred and PartQtyDeferred

SELF-PROMOTION:
During my “Case of the Unusual” at Insights 2016, one of the examples I used was a Deferred table and the various ways to triage issues with it. So, those on the fence on Insights 2017, come on down! Additionally, I’ll be discussing some of my favorite things about 10.1 at the MN EUG this week, and this will be one of the topics I’ll be speaking to.

Deferred tables are there to eliminate contention. When you have processes like MRP with multiple threads (processors/schedulers) and what happens if two of those both need to change the PartQty? Locking/blocking/deadlocks <-- fun fact: deadlocks are almost 100% software issues assuming of course that there aren’t any external processes in play. So, what we did instead is for processes that have current threads trying to update the same records (MRP, Posting) we created these deferred tables to insert a new record into the deferred table instead of updating the actual record directly to avoid the contention. After the transaction is complete, the actual record is updated - so in practice, it isn’t slower. There is some additional logic that says that after a period of time if that record is in the deferred table too long (~15 minutes I believe) it will process it immediately like if the appserver went down in the middle of processing - this is triggered from the taskagent.

1 Like