A Look at Max Concurrent Process Definition Property

Let’s take a look at the Process Definition property called Max Concurrent. This property is defined on the first page of the process definition. This is a simple numeric property where you can tell the process scheduler how many concurrent processes can be run of that type.

There are several situations where you may not want more than some number of instances of a process to run at the same time. I find it useful in certain situations to ensure only one instance of a process is run at a time.

There are many situations where you may want to use this property. A few that come to mind are:

• If more than n concurrent processes of the same type causes a system slow down.
• If the process creates a lock on a common file. For example, the process is always looking for a file name called “input.txt” in some shared directory. You don’t want more than one process trying to read or write to the file.
• Your process is not designed for concurrent processing because it populates some reporting table which does not have a key structure to handle more than one process inserting into it.
• The process is long running and performs system updates in a single database transaction. Another instance of the same process may try to update the same data which would be incorrect.

The process scheduler is responsible for enforcing this. In the screen-shot above, I setup the process to only have one max concurrent instance. What happens when we queue up several instances using different request parameters? The process monitor will actually show the ones queued up as “blocked”. Here is screen-shot that shows several instances that are blocked.

Please note that when I captured this screen-shot, I had just scheduled the top two processes which are still in “queued” status. The next two below are “blocked”. Since the process scheduler has a “heart-beat” and periodically checks the process request table for new work, I actually snapped this screen-shot in between heart-beats and the process scheduler server had not had a chance to look at the new requests (at the top) and flip them to “blocked”. If I would have waited a few seconds those top two would have been flipped to “blocked” as well.

I have found that using this property can solve “mystery” issues with certain processes.