BPMN Deadlock

One danger of using a precise language like BPMN to describe business processes is that you can precisely get yourself into trouble. Deadlock (in BPMN) is a condition used to describe a process that can’t be completed. By designing (or describing) the wrong business process, you can create a process that never finishes.

Rewarding the Pedants

At the end of our earlier article about compensation events, we hinted that there was another problem with the diagram we debugged. That problem was deadlock. We diagrammed a process that could never complete. Congrats to the people who caught it!

A Simple Deadlock Example

Take a look at the following process diagram and see if you can identify the deadlock condition. Here’s a hint – you might want to review how gateways work in BPMN.

The process splits at an inclusive OR gateway, and then joins together with a parallel gateway. The deadlock case (a process that can’t complete) comes from the precise nature of the definitions.

• Flow from an inclusive OR gateway will follow at least one, and could follow some or all of the paths that leave it.
• Flow into a parallel gateway requires that all incoming paths be resolved before continuing

When the salesman sells more than twenty cars, both paths are taken from the OR gateway, and then both paths are combined in the parallel gateway. There is no deadlock condition. We have a problem when the salesman sells twenty or fewer cars.

In the problem case, one of the paths (“More than 20”) is not taken by the process (the salesman does not get a bonus). The parallel gateway still requires both paths before completing – it has no way of knowing that the bonus-path was never started (or rather, the parallel gateway doesn’t care). So the parallel gateway will “hold up” the process until both input paths are completed. Since the “bonus path” is never started, the parallel gateway will never be satisfied and the process will never finish. This is what BPMN folks call deadlock.

Simple Solution To A Simple Problem

The solution for this illustrative example is as simple as the problem.

The parallel gateway that joins the flows together before “Pay Bills” has been replaced with an inclusive OR gateway. This gateway specifically waits for every path that was activated. When only one path is initiated, only one path is required. When both paths are started, then both paths must be completed before proceding.

A More Complex Example

This example is more along the lines of the mistake we referenced in our earlier article.

In this example, our actor attempts to walk and chew gum at the same time. If he trips, he will reach one of the end events, but he won’t achive the multitasking award. At first glance this seems acceptable – the process starts and ends, and the actor doesn’t get a multitasking award.

However, this process is also deadlocked, because of the join gateway. The join gateway must complete both of the incoming sequence flows – but if the actor trips, the flow from the XOR gateway (trip?) will not be activated and the gateway will never complete.

A More Complex Solution

The key to solving this deadlock problem is to make sure that all of the paths into the parallel gateway are completed.

The XOR gateway (trip?) is now processed after the two sequence flows are reconnected. If the actor tripped, he will not receive the multitasking award. If the actor didn’t trip, he would.

Summary

When using parallel gateways to join paths, we must make sure that all incoming paths are handled. We can avoid the deadlock problem by replacing a parallel gateway with an inclusive OR gateway. We can also resequence our process steps to assure that all incoming sequence flows to a parallel gateway are activated.