Page 258 -

252 M. Adams
when a suspended work item is unsuspended, it always reverts to the status it
held immediately before it was suspended.
Every work item created for a task will eventually reach a completion status. As
stated earlier, once all (or the specified threshold) of the child instances have reached
a completion status, the parent instance also completes, and the task itself is said to
have completed. The five completion statuses are the following:
Complete: The work item has completed normally, typically via a check-in
request from a Custom Service
ForcedComplete: The work item was executing and has been forced to com-
plete, typically by an exception handler. This status implies that the work item
was not completed in the normal manner, but the process should move to the next
task(s) in the control-flow (i.e., when all work items of the task are completed,
the task should produce a token in each of its output places, depending on any
split decorator the task may have)
Canceled: The work item has been canceled, perhaps because the case has been
canceled, or the work item is a member of another task’s cancelation set, or via
an exception handler
Failed: The work item has been forced to fail. This status is similar to canceled,
except that the task from which the work item was created should not produce a
token in any of its output places (i.e., control-flow on that arc of the process that
contains the task is blocked)
Deadlocked: This is a “special” status that is given to work items that may oth-
erwise have eventually been enabled (i.e., the task has tokens in one or more of
its input places, but not all of the places sufficient to enable it), except for the fact
that the overall process has reached a deadlock state (i.e., it has not completed,
but cannot continue). Such work items are created with a status of Deadlocked
solely for the purposes of logging the fact that a deadlock has occurred. Once this
status change has been logged, they are immediately removed from the Engine

9.6 Persistence

A single instance of a workflow process will take a certain amount of time to com-
plete. Some may be short-lived, but others may run for days or weeks (e.g., an
order fulfillment process) or even months (conference organization) or, for some
processes, years (a course of study). However, like any computerized process, work-
flow instances are susceptible to interruptions or failures on the hardware hosting
them. For all processes, it is imperative that if such an outage occurs, the work
performed thus far for a process is not lost. To guard against the potential loss of
process information as a result of server downtime, all YAWL process instances may
be persisted.
Data persistence refers to the mechanism of saving to permanent data storage
(i.e., a disk) all data relevant to a process, so that in the event of an outage, on restart