![](bg3.png)
Case 2: Assume that the balance of unpaid bills of a
customer has a predefined upper limit. The balance
is checked in the task Check creditability, and if the
new order would cause an overdraft then the work-
flow is aborted (a semantic failure). Otherwise, the
new balance is updated in the task Charge customer.
Now, to ensure that the limit will not be executed as
a result of two or more concurrent workflows of the
same customer, the workflows pertaining to the
same customer should be processed in a serializable
way, or at least the tasks Check creditability, Insure
transportation and Charge customer pertaining to the
same client should be processed in a serializable
way.
Case 3: Assume that the existence of an ordered
product is checked in the task Purchase chemical,
and that the ordered product is not removed from
chemical provider’s inventory database until in the
task Order transportation task. Now, to ensure that
the ordered product is still in the inventory, the task
Purchase chemical and Order transportation should
be executed as one transaction, or at least they
should constitute a unit of isolation.
3 TRADITIONAL
CONCURRENCY CONTROL
METHODS
We now give a short introduction to the notions that
are related to concurrency control. In particular, we
consider the notions that we use in later analysis.
Concurrency control is the activity of
coordinating the actions of processes that operate in
parallel, access shared resources, and therefore
potentially interfere with each other (Bernstein et al,
87). A scheduler is a program that controls the
execution of concurrent activities (Gray & Reuter,
93). When it receives an operation it may
immediately schedule it, delay it, or reject it. Each
scheduler usually favours one or two of these
choices.
Almost all types of schedulers have an
aggressive and a conservative version. An aggressive
scheduler tends to avoid delaying operations, and so
it loses the opportunity to reorder operations it
receives later on. A conservative scheduler tends to
delay operations, and so it can reorder operations it
receives later on.
Locking is the most common type of schedulers
(Bernstein & Newcomer, 1997). The idea behind
locking schedules is intuitive: each resource to be
accessed (e.g., data item or a web service) has a lock
associated with it, and before an activity (e.g.,
transaction or workflow) may access a resource, the
scheduler first examines the associated lock. If no
activity holds the lock then the scheduler obtains the
lock on behalf of the re-questing activity.
With timestamp methods a unique time stamp is
assigned to each transaction. Transactions are then
processed so that their execution is equivalent to a
serial execution in timestamp order. This
concurrency control mechanism allows a transaction
to access a data item only if it had been last accessed
by an older transaction; otherwise it rejects the
operation and restarts the transaction.
Each type of scheduler works well for certain
types of applications. We will show that an
aggressive scheduler based on timestamp ordering
method will work well with multiparty business
processes. However, the traditional correctness
criterion would be overly restrictive and therefore
we will introduce a more liberal correctness
criterion.
4 CONCURRENCY CONTROL
CRITERIA
A natural and sufficient criterion for isolation
correctness is that the execution is serializable, i.e.,
equivalent to a serial execution. Moreover this
traditional criterion is intuitive and clear. However,
though it is suitable for traditional transactions it
would overly restrict the concurrency of long lasting
activities such as multiparty workflows. However,
by using semantic information it is possible to
weaken the serializability criterion, and yet ensure
execution correctness. On the other hand, analogous
with traditional semantic concurrency control
models (Lynch, 1983; Garcia-Molina 1983) the use
of semantic information makes the specification as
well as the management of the system more
complex.
With multiparty workflows the requirements for
concurrency control significantly deviates from
those used with databases. In particularly there are
no consistency constraints between the data stored in
communicating applications but rather (as illustrated
in Section 2) the workflows may interfere with each
others through accessing dirty data (i.e., data that is
written by uncommitted activities). Therefore
neither the correctness criterion nor the concurrency
control methods (e.g., two-phase locking) developed
A CONCURRENCY CONTROL MODEL FOR MULTIPARTY BUSINESS PROCESSES
211