Pattern 31 (Data Transfer by Reference - With Lock)

FLASH animation of Data Transfer by Reference - With Lock pattern

Description

The ability to communicate data elements between process components by passing a reference to the location of the data element in some mutually accessible location. Concurrency restrictions are implied with the receiving component receiving the privilege of read-only or dedicated access to the data element. The required lock is declaratively specified as part of the data passing request.

Example

At conclusion, the Allocate Client Number task passes the locations of the new client number and new client details data elements to the Prepare Insurance Document task, which receives dedicated access to these data items.

Motivation

As for the previous pattern, this pattern communicates data elements between process components via a common data store based on common knowledge of the name of the data location. It provides the additional ability to lock the data element ensuring that only one task can access and/or update it at any given time, thus preventing any potential update conflicts between concurrent tasks which may otherwise attempt to update it simultaneously or continue to use an old value of the data element without knowledge that it has been updated.

Overview

This approach is an extension of the Data Transfer by Reference - Unlocked pattern (WDP-30) identified above in which there is also the expectation that the originating process component has acquired either read-only or exclusive (write) access to the specific data elements being passed (i.e. a read or write lock). The process component that receives these data elements can choose to relinquish this access level (thus making them available to other process components) or it may choose to retain it and pass it on to later components. There is also the potential for the access level to be promoted (i.e. from a read to a write lock) or demoted (i.e. from a write to a read lock).

Context

There are no specific context conditions associated with this pattern.

Implementation

This pattern is not widely implemented in the offerings examined. iPlanet is the only workflow engine to directly support it. BPEL provides an approach to concurrency control through the use of serializable scopes which allow fault and compensation handlers to be defined for groups of process activities and allow access to a given data element to be restricted to a single task instance at any given time. BPMN and UML 2.0 ADs both utilize a "token-based" approach to data passing in which data objects are consumed at task commencement and emitted at completion hence they both support this pattern. FLOWer provides limited support for a style of write lock which allows the primary case to modify data whilst still enabling it to be accessible for reading by other processes.

Issues

None observed.

Solutions

N/A.

Evaluation Criteria

An offering achieves full support if it has a construct that satisfies the description for the pattern. It is rated as partial support if the locking requirements cannot be declaratively specified as part of the data passing request.

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.

Summary of Evaluation