In the past we often had the need to build up some que and de-que algorithm within Microsoft Dynamics 365 for Finance and Operation. What we normally use in such scenarios is a simple SQL table to manage the que entries. The problem with this solution is, when many processes try to que and de-que, you will end up with high locking contention. The solution to reduce the locking contention is the so called “top picking pattern” which has been described in the linked site: https://blogs.msdn.microsoft.com/axperf/2012/02/28/batch-parallelism-in-ax-part-iii/
One key factor of the “top picking pattern” is that the de-que algorithm always runs on ttslevel 0 because it will set an exclusive lock on the que table to pick the topmost entry from the que and releases the lock directly after the picking. The processing of the picked entry happens afterwards in a separate transaction.
Our best practice for implementing the “top picking pattern” is to add only one (non-unique) index to the que SQL table which has only one boolean field with name Proceed. With this implementation pattern we are able to optimize the write performance as much as possible.
What are your experiences with que and de-que algorithm within MSDyn365FO?