Pattern 39 (Critical Section)
Two or more connected subgraphs of a process model are identified as "critical sections". At runtime for a given process instance, only tasks in one of these "critical sections" can be active at any given time. Once execution of the tasks in one "critical section" commences, it must complete before another "critical section" can commence.
Both the take-deposit and insurance-payment tasks in the holiday booking process require the exclusive use of the credit-card-processing machine. Consequently only one of them can execute at any given time.
The Critical Section pattern provides a means of limiting two or more sections of a process from executing concurrently. Generally this is necessary if tasks within this section require exclusive access to a common resource (either data or a physical resource) necessary for a task to be completed. However, there are also regulatory situations (e.g. as part of due diligence or quality assurance processes) which necessitate that two tasks do not occur simultaneously.
The operation of this pattern is illustrated in Figure 57. The mutex place serves to ensure that within a given process instance, only the sequence BD or CE can be active at any given time.
Figure 57: Critical section pattern
There is one consideration associated with the use of this pattern: tasks must be initiated and completed on a sequential basis, in particular it is not possible to suspend one task during its execution to work on another.
Although useful, this pattern is not widely supported amongst the offerings examined. BPEL allows it to be directly implemented through its serializable scope functionality. COSA supports this pattern by including a mutex place in the process model to prevent concurrent access to critical sections. FLOWer provides indirect support through the use of data elements as semaphores.
Full support for this pattern is demonstrated by any offering which provides a construct which satisfies the description when used in a context satisfying the context assumption. Where an offering is able to achieve similar functionality through additional configuration or programmatic extension of its existing constructs (but does not have a specific construct for the pattern) this qualifies as partial support.
To achieve a + rating (direct support) or a +/- rating (partial support) the product should satisfy the corresponding evaluation criterion of the pattern. Otherwise a - rating (no support) is assigned.
|Staffware||10||-||Not supported. Since Staffware always immediately schedules subsequent activities, there is no way of temporarily blocking them. Note that withdrawing a step does not solve the problem.|
|Websphere MQ||3.4||-||Not supported. Subsequent activities are scheduled immediately thus removing any potential for restricting concurrent execution of activities.|
|FLOWer||3.51||+/-||Not directly supported. However, data elements can acts as semaphores. There are no concurrency problems because of the write-lock on cases.|
|COSA||5.1||+||Supported through the use of a mutex place to prevent concurrent access to the critical section.|
|iPlanet||3.0||-||Not supported. Although custom router conditions could be specified that access a mutex variable to determine when an activity can proceed, there is no means of managing concurrent access to the variable.|
|SAP Workflow||4.6c||-||Not supported. There are no mechanisms other than events and cancellations to support interactions between parallel branches.|
|BPEL||1.1||+||Supported by serializable scopes.|
|Websphere Integration Developer||6.0||+||Supported by serializable scopes.|
|Oracle BPEL||10.1.2||+||Supported by serializable scopes.|
|BPMN||1.0||-||Not supported. No means of limiting concurrent execution of a set of activities.|
|XPDL||2.0||-||Not supported. No means of limiting concurrent execution of a set of activities.|
|UML ADs||2.0||-||Not supported. No means of preventing concurrent execution of a set of activities.|
|EPC (implemented by ARIS toolset 6.2)||-||Not supported. There is no way to create a kind of mutual exclusion state.|
|jBPM||3.1.4||-||jBPM does not support this pattern.|
|OpenWFE||1.7.3||-||OpenWFE does not support this pattern.|
|Enhydra Shark||2||-||Enhydra Shark does not support this pattern, as there is no mechanism for limiting concurrent execution of a set of activities.|