Pattern 39 (Critical Section)

FLASH animation of Critical Section pattern

Description

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.

Examples

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.

Motivation

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.

Overview

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

Context

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.

Implementation

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.

Issues

None identified.

Solutions

N/A.

Evaluation Criteria

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.

Product Evaluation

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.