An Algorithmic Approach for Deadlock
Detection and Recovery in Inter Organizational
Cooperative Workflows

First A. Jiju P, Second B. Amith Hariharan, Third C. Prashobh Balakrishnan, Fourth D. Vijith K, Fifth E.
Manas Kumar Singh, and Sixth F. Vivek R Nath
Abstract— This paper aims at designing a conceptual model for
inter organizational cooperative workflows based on Bonita
workflow model. Even though many workflow models have been
proposed in the literature, Most of the models lack a sound deadlock
detection and recovery mechanism. In virtual enterprise scenario
where parallel activities from various participating organizations
collaboratively work on accomplishing a common goal, there is often
a chance for occurrence of dead lock. In this context, an algorithm for
detecting possible deadlocks and recovering from it is designed in
this paper. This paper also details the various modifications done to
the Bonita work flow model so as to incorporate the newly designed
algorithm.
Keywords— workflow model, cooperative workflow, Inter-
Organizational workflows, deadlock, Bonita.
I. INTRODUCTION
The boom in Internet and distributed computing
technologies has helped the business organization to conduct
business over the Internet. Workflow management systems are
widely used to manage business in distributed environment.
Workflow management systems play an immense role in this
inter-organizational collaboration to automate the participating
business process.
When two or more organizations come together over the
internet and work together for a common mission, a high
degree of cooperation and coordination among the various
participating business activities and members are unavoidable
which may lead to deadlock among the participating activities.
A cooperative workflow can be defined as a workflow in
which activities executing in parallel can share some
intermediary results along with resources during execution. In
the inter-organizational environment, the participating

Manuscript received September 20, 2010. An Algorithmic Approach for
Deadlock Detection and Recovery in Inter Organizational Cooperative
Workflows
F. A. Jiju P is with MEA Engineering College, Perinthalmanna, india
(94978100114; e-mail: jijupnair2000@ yahoo.co.in).
S. B. Amith hariharan, was with MEA Engineering College,
Perinthalmanna, india (e-mail: amithhariharan@gmail.com).
T. C. Prashobh Balakrishnan, was with MEA Engineering College,
Perinthalmanna, india (9496364549,e-mail:prashobh.e@gmail.com).
F. D Vijith K, was with MEA Engineering College, Perinthalmanna,
india(email: vijithk999@gmail.com).
F. E Manas Kumar Singh was with MEA Engineering College,
Perinthalmanna, india(email: manassingh64@gmail.com).
F. F Vivek R Nath was with MEA Engineering College, Perinthalmanna,
india(email: vivekrnad@gmail.com).
activities will be from business processes of different
organizations. So cooperation policies should be an integral
part of cooperative workflow systems to ensure consistencies
among the various shared results and synchronization among
the activities sharing some results and should check for the
deadlock and should recover from it.
To ensure coordination and cooperation between various
inter organizational activities, we have adopted a conceptual
model of inter-organizational cooperative workflows proposed
in [1] which is based on Bonita model. Bonita [2], is open
source workflow software from Object Web consortium,
which supports cooperation, though it has been mainly used
for traditional applications. Still this model does not have a
provision for deadlock detection and recovery. We are
modifying this model to incorporate deadlock detection and
recovery technique into it.
Rest of this paper is organized as follows. Section II
explains Proposed Cooperative Workflow Model, section III
describes Modified version of the Transaction Protocol [8,9]
which maintains consistency among the activities of various
business organizations, section IV details Deadlock Detection
and Recovery mechanism, section V gives Algorithm for
deadlock detection and Recovery and section VI concludes the
paper followed by references.
II. COOPERATIVE WORKFLOW MODEL
Cooperative workflow model allows the activities to share
their intermediate results not only at the beginning or end, but
also in the middle of execution. In an inter-organizational
scenario, where activities from different organization may
work collaboratively on some common task/project, there
should be a proper cooperation mechanism underlying the
model. Here we adopted the conceptual model of inter
organisational cooperative workflow [1], and modified it to
add some more states.
Different stages of life cycle of an the activity are explained
below.
Initial: In this state, an activity waiting for some processing
to be completed before being ready to run. In the case of
normal activities, at least one of the parent activities is still
executing. In the case of anticipatable activities, if at least one
of the parent activities has not yet started.
Ready: Activity is ready to start. There are two possible
situations for this state to occur. In the first situation, an
activity has no parent activity (this is the first activity of the
 INITIAL

Parents executing or anticipating

Parent process ends & transition condition met Parents executing or anticipating
Parents executing or anticipating Parents executing or anticipating
Parents executing or anticipating arents executing or anticipating
arents executing or anticipating READY ANTICIPATABLE
relationship is still running. Because of the
Exception Handled
Parents executing orStart
anticipating Parent process ends & transition
Start condition met dependency, the activity cannot be terminated. This
ParentsException
arents executing or
Parents
Parents
executing
executing Encountered
or anticipating
executing
anticipating
or anticipating
Parents
or
Parents executing or anticipating
executing or anticipating
anticipating Parents executing or anticipating
state has been added to the model to incorporate the
Parents
Parents executing or anticipating executing or anticipating
arents executingarents
HANDLINGParents executing or anticipating
or anticipating
EXECUTING
arents executing
executing or anticipating or anticipating
ANTICIPATING COO transaction protocol [9] into the workflow
EXCEPTIONarents executing or anticipating which forms the foundation for cooperation among
Cancel/Transition condition met
Produce final results & partner activityCancel
Finish
still executing
Parents executing or anticipating
Parents executing or anticipating
the activities.
Receive external update message/transition condition Resume
met executing
Parents Parents
or anticipating
Parents
Parents executing or anticipating
executing or anticipating Paused:
Parents executing or anticipating Parents executing or executing
arents executingororanticipating
anticipating arents executing or anticipating
anticipating
TERMINATED
Parents executing or anticipating Parents
arents executing executing or anticipating
or anticipating This is a state of an activity where user explicitly
arents executing or anticipating
arents executing or anticipating pauses a running activity for some reasons. This state
Explicit pause by user
Update complete Parents executing or anticipating
Timed out
Parents executing or anticipating
gives flexibility to the workflow system. The activity
Parents executing or anticipating
ParentsCOMMUNICATING
executing or anticipating
Parents executing or anticipating
arents executing or anticipating
Parents executing or anticipating
PAUSED
will resume execution when user does the appropriate
COMPLETED arents executing or anticipating
arents executing or anticipating action. An activity in the pause state will be
Provide final results/partnerSend
activity
groupstill executing request and receive positive acknowledgement/receive group termination request terminated after a specified time interval.
termination
Parents executing or anticipating
Parents executing or anticipating
Deadlocked: An activity can reach this state at two
arents executing or anticipating instances
READY TO
COMPLETE First, an activity in ready to complete state can go
Partner activity still executing
to deadlock if its partner activities are in deadlock,
Activity participates in a group
Trigger deadlock recovery process
DEADLOCK
otherwise the activity may be a anticipatable activity
DEADLOCKED RECOVERY waiting for its parent to be completed can go to
deadlock if its parent is in deadlocked state.
Fig.1 Proposed work flow model Handling Exceptions:
Parents executing or anticipating
Parents executing or anticipating An executing activity will go to exception handling
arents executing or anticipating
state when any of the exceptions are encountered.
workflow process). Otherwise, a normal activity has parent Exceptions may be of behavioural, semantic or system based.
activities that have terminated successfully. Once the exceptions are handled, activity goes to running
Besides this, the transition conditions of the parent activity state.
to this activity have been successfully met. Deadlock Recovery: When an activity becomes
Executing: It is state where activity executes predefined deadlocked the deadlock recovery procedure is triggered and
actions. activity reaches this state. Chances for future deadlock are
Anticipatable: This is the state of an activity that can be avoided and the activity goes to ready to complete state.
started without waiting for its parent activity(s) to complete.
However, all of the parent activities must have started.
Anticipating: An anticipatable activity that has been
III. MODIFIED TRANSACTION PROTOCOL
started. However an anticipating activity cannot be terminated
until all parent activities have terminated and the transition Proper handling of cooperative model was described by COO
conditions have been successfully evaluated. Protocol in [1].
Terminated: A cancelled activity. This occurs in two Modified COO protocol is explained which provides an
situations. An activity can be explicitly cancelled or an operational semantics of the modified model [2][3] of Bonita.
unsuccessful evaluation of an inner transition condition. COO transaction protocol is applied to activity level which
Completed: An activity that has been completed will make the best utilization of the protocol in cooperative
successfully. In addition to the states given here, some more model.
states have been added to the Bonita model to make it efficient
cooperative workflow model.
Communicating: The activities go to this state when they 1. A result produced before the end of an activity is an
want to access any resource from other activities or when they intermediate result. Users can send an intermediate result
receive a request for its own resource from other activities. from one activity to another activity using
The resource may be the intermediary results of the activities. onCommunicate hook which is added feature into
Another instance where the activity can go to the Modified Bonita model [2].
communicate state is when the activity ask for any updates in
other parallel activities on which it is dependent. Once the
activity goes to communicating state, it may return to 2. A result produced at the end of an activity is a final result.
All final results are produced automatically during the
executing state, provided the requested resource is sent or
execution of the complete operation.
received or the updates are complete. The dependent activities
which have already produced its final results can go to Ready
to Complete (RTC) state if its partner activity in the 3. An activity that produces an intermediate result must
dependency relationship is still executing. produce a corresponding final result. The protocol collects
Ready to Complete: all the objects that were defined by onCommunicate hook
As already mentioned in the communicating state, an in the activity by the process and automatically produces
activity goes to RTC state when it completes its execution and a final result for each of them during the complete phase
produces final results but its partner activity in the dependency of the activity.

4. If an activity reads an intermediate result, then it must
read the corresponding final result. The protocol
maintains a directed edge between activities to memorize
the fact that an activity reads an intermediate result of
another activity among the group of activities. When an
activity A1 reads the intermediate value of an object x
produced by another activity A0, then a directed edge
A0→A1 is created. When the activity A1 reads a value x of
A0 and A0 is completed then directed edge will be
removed.
5. An activity cannot complete if it is still dependent on
another activity. If an activity tries to reach ready to
complete (RTC) state without reading the final result, that
operation will be eliminated and the activity remains
active.
6. Activities involved in a cyclic dependency graph form a
group.
7. A group-member activity can start a group completion by
trying to complete it. The complete operation in this case
produces a set of potentially final results and changes the
state of the activities from executing to ready to complete
(RTC).
8. When a group-member activity tries to complete and all
the other group-members are in the RTC state, then all the
activities are completed simultaneously.
9. When a group-member activity tries to complete and there
is another group-member still executing, then it produces
new potentially final results and enters the RTC state.
10. If a group member produces a new intermediate result
during the group completion phase, then this completion
tentative is aborted, and all the group members re-enter
the executing state.
IV. DEADLOCK DETECTION AND RECOVERY
In computer science, deadlock refers to a specific
condition when two or more processes are each waiting for
each other to release a resource, or more than two processes
are waiting for resources in a circular chain. Deadlock is a
common problem in multiprocessing where many processes
share a specific type of mutually exclusive resource known as
a software lock or soft lock. Computers intended for the time-
sharing and/or real-time markets are often equipped with
a hardware lock (or hard lock) which guarantees exclusive
access to processes, forcing serialized access. Deadlocks are
particularly troubling because there is no general solution to
avoid (soft) deadlocks.
This situation may be like two people who are
drawing diagrams, with only one pencil and one ruler between
them. If one person takes the pencil and the other takes the
ruler, a deadlock occurs when the person with the pencil needs
the ruler and the person with the ruler needs the pencil to
finish his work with the ruler. Both requests can't be satisfied,
so a deadlock occurs.
In the context of work flow, where activities are
represented using diagraphs, detection of deadlocks is done by
cycle detection algorithm which is widely used in the literature
of graph theory. If all the activities participating in a cycle are
in ReadyToComplete state, then it represents a deadlock
situation as per the modified transaction protocol and the
states of all the activities will be changed to Deadlocked state.
In P1 P2 order to
recover from a
P3
Fig.2 A Normal deadlock involving three activities
deadlock, we introduce a new method called as dummy
activity method. As per this algorithm we create a replica of
an activity which is termed as initiator activity (an activity
which starts cycle termination process), which is in the
Deadlocked state. Once the dummy activity is created, the
states of all the group member activities will be changed to
DeadlockRecovery state and the procedure will freeze the
P1
D.P1
P3 P2
Fig. 3. Creating copy of process P1
initiator activity. An input for the initiator activity is given to
the dummy activity which will start to run and produce some
results, then output produced by the initiator activity will be
compared against the pattern which we already defined and
stored as part of the expected inputs of next activity. Then the
second activity will continue the same and finally the activity
to which initiator activity is dependant will produce its final
result. Now this result will be given to initiator activity after
unfreezing it and which in turn will trigger the group
completion.
In Figure 2, we have a normal dead lock situation with three
concurrent activities p1, p2, and p3. They could run to
completion only if any of the deadlocked activity produces its
final result. A copy of the activity p1 will be created and
assume an input is given to the dummy activity D.P1 as shown
in the figure 3.
D.P1 P1
 P2

Using that input the activity will run and produce an
output which is given to activity p2 as its input according to
that p2 will produce some results consequently the others and
we keep these out puts in to a buffer. As per the algorithm, a
stack will be kept which will store the predefined output of
each process.
We compare each output with these patterns and check the
correctness of the process. Then initiator will be given the
output produced by the activity P3 and the group termination
will be occurred. The figures show how it can be recovered
from a deadlocked situation.
P3
activity. Set of activities present in cyclic graph is output of
cycleDetector procedure.
Fig.4. Replace P1 with D.P1 and freeze P1
Procedure cycleDetector()
Input : Digraph G, Activity1, Activity2.
Output : A set of vertices CycleSet.
marked[1..n] : boolean array used for marking whether a node

V. ALGORITHM is visited or not during DFS call. All

elements in marked[1..n] is initialized to
A brief algorithm and associated procedures are given FALSE.
below. The main entry point to the deadlock detection and
recovery is the procedure deadlockHandle(). done[1..n ] : boolean array used to indicate whether DFS
is
Procedure deadlockHandle() done on a certain vertex or not. All elements
Input : Digraph G in

Output : Modified Digraph G done[1..n] is initialized to FALSE.

1: if Cycle Detect then

2: if all states are RTC then 1: marked [Activity1] = TRUE;
2: for w ∈ adjacent of Activity1 in G do
3: Deadlock-1;
4: Recovery -1; 3: if marked[w]! = TRUE then

5: else 4: if done[Activity2] != TRUE then

6: if States Idle & RTC then 5: add w to CycleSet;

7: Deadlock-2; 6. end if

8: Recovery-2; 7: CycleDetector(G,w,Activity2); //recursion

9: deadlockHandle(); //recursion 8: if done[Activity2] != TRUE then

10: else 9: remove w from CycleSet;

11: if one Executing state & others are RTC 10: end if
state then 11: else if done[w]! = TRUE then
12: request for group completion; 12: if done[Activity2] != TRUE then
13: end if 13: add w to CycleSet;
14: end if 14: done[w] = TRUE;
15: end if 15: end if
16: end if 16: end if
A flowchart for procedure deadlockHandle is shown in Fig-3 17: end for
which gives more clear description about the main role of
deadlock handling procedure. 18: if done[Activity2] != TRUE then
A. Procedures for deadlock Handle 19: remove Activity1 from CycleSet;
Here cycleDetector and groupCompletion procedure are 20: end if
played supporting role for deadlockHandle procedure.
21: done [Activity1] = TRUE;
B. Cycle Detection
22: return CycleSet.
In cycleDetector procedure, Depth First Search (DFS)
algorithm is used for detecting cyclic dependency. Digraph, Start
Activity1 and Activity2 are the inputs for cycleDetector. At
beginning parameters Activity1 & Activity2 are set to same

Detect Cy
 C. Request for Group Completion Output : Modified Digraph G.
groupCompletion procedure will remove the cyclic 1: if Activity1& Activity2 ∈ G then
dependency from the Digraph. Digraph and Activity1 are the
2: remove an edge between Activity1 &Activity2;
inputs for groupCompletion procedure.
3: else End
Procedure groupCompletion()
4: abort the request;
Input : Digraph G, Activity1.
t 5: end if
Output : Modified Digraph G.
Procedure addVertex()
Input : Digraph G, Activity1.
1: allRTC=TRUE;
Output : Modified Digraph G.
2: if Activity1 ∈ G then
1: if Activity1 ∉ G then
3: if Activity1 ∈ any cycle of G then
2: add Activity1 in G;
4: CycleSet = CycleDetector(G, Activity1);
3: associate time stamp TActvity1for that activity;
5: while vi ∈ CycleSet do 4: else
6: if vi ! = RTC then 5: abort the request;
7: allRTC = FALSE; 6: end if
8: end if
9: end while Procedure removeVertex()
10: if allRTC = TRUE then Input : Digraph G,Actvity1.
11: Initiator=findInitiator (G, CycleSet); Output : Modified Graph G.

12: deadlockRecovery(G,Initiator,CycleSet); 1: if Activity1 ∈ G then

13: end if 2: remove Activity1 from G;

14: end if 3: else

4: abort the request;
15: end if
5: end if

5.4 Extra Procedures

Procedure findInitiator()

Some extra procedures like addEdge, removeEdge, addVertex Input: Diagraph G, Set of activities CycleSet.
and removeVertex are also used. Digraph, Activity1 and Output: Initiator Activity.
Activity2 are the inputs for addEdge and removeEdge. But ∈ CycleSet
only Digraph and Activity1 are the inputs for addVertex and 1: for all vi , vj
removeVertex procedure. 2: If T vi> T vj then
Procedure addEdge()
3: Initiator=Vi
Input : Digraph G, Activity1, Activity2.
4: else
Output : Digraph G with new vertices.
5: Initiator=Vj

1: if Activity1 sends data to Activity2 then 6: return Initiator

2: create an edge Activity1 → Activity2;

3: else if Activity1 requests data from Activity2 then
4: create an edge Activity2 → Activity1; Procedure deadlockRecovery()

5: end if Input: Diagraph G, Initiator Activity, Set of Deadlocked Activities

CycleSet.
Output: Null
Procedure removeEdge ()
1: Create a dummy activity for Initiator and copy all input and output
Input : Digraph G, Activity1, Activity2. characteristics of Initiator to dummy.
2: for all dependency, Initiator→ vj | vj → Initiator ∈ CycleSet [2] Bonita workflow:”Bonita API” reference guide of Bonita v3.1,
September 2007.
3: create dummy→ vj & vj → dummy in CycleSet [3] Annappa B, Jiju P, Dr.K Chanasekaran, K C Shet,” Petri net
4: freezeEdge (Initiator, vj) and freezeEdge (vj ,Initiator) based Verification of a Cooperative Work flow Model”,
International conference on Network Digital Technology
5: end for 2009(NDT,’09),pp 82-87, 28-31 July, 2009.
∈ [4] M Hema sundari, Anup K sen, Amithava Bagchi,”Workflows
6: for all ai Output Characteristics of dummy as UML activity diagrams :Analytical method for control flow
verfication”,September 2008
7: start executing from dummy/ai → vj and complete the
[5] Bonita. http://bonita.objectweb.org/ [last visited: 11 September,
cycle at vi/bi→dummy 2010].
[6] Peng Liu, Tingting Fu, Ming Cai, Huaidong Shi, “An Improved
8: if result of vi/bi→dummy == any of the input
Cooperative Model for Web Service Based Workflow
characteristics of dummy then Management”, Proceedings of the 11th IEEE International
Conference on Computer Supported Cooperative Work in
9: unfreezeEdge(Initiator, vj) and
Design, pp. 818-822, 26-28 April, 2007.
unfreezeEdge(vj ,Initiator) [7] Bin Yan and Feng-Jian Wang, “A Cooperative Framework for
Inter-Organizational Workflow System”, Proceedings of 27th
10: remove dummy Activity from the cycleSet.
IEEE Annual Conference on Computer Software and
11: end if Applications (COMPSAC’2003),pp.64-71,3-6 November, 2003.
[8] C. godart, F. Charoy, O. Perrin and H. Skaf-Molli ,
12: end for “Cooperative workflows to coordinate asynchronous
cooperative applications in a simple way”, Proceedings of
13: start executing from Initiator/ ai → vj and complete the cycle. Seventh IEEE International Conference on Parallel and
Distributed Systems, pp. 409-416,4- 7 July, 2000.
14: end Procedure [9] Munier, K. Bengali and C. Godart, “A Transactional Approach
for Cross-Organizational Cooperation” IEEE Conference on
Global Telecommunications (GLOBECOM’99), pp.1926-1931
Procedure freezeEdge() Vol.3, 1999.
[10] Wil van der Aalst and Kees van Hee [2000]: “Workflow
Input: Activities vi,,vj Management: Models, Methods and Systems”, MIT Press.
[11] WfMC, Workflow Reference Model.
Output: null
1: Make the egde (vi, vj) inactive
First A. Jiju P (1983–) is a Lecturer in Dept. of
2: end Procedure Computer Science & Engineering in MEA Engineering
College, Perinthalmanna, India. He has completed his
B. Tech in Information Technology from Calicut
University, India. He received his M.Tech in Computer
Procedure unfreezeEdge() Science from NITK, Surathkal, India. He is keen on
research fields like Parallel algorithms and Computing,
Input: Activities vi,,vj Complexity Theory, Computational Biology.

Output: null
1: Make the egde (vi, vj) active

2: end Procedure

VI. CONCLUSION
Lot of research is going on in the area of workflow
technology, as it has become an essential part of the business
organizations. Emphasis is given to design and incorporate
deadlock detection and recovery algorithm into the traditional
workflow model to provide a deadlock free environment
having flexibility and cooperation in inter organizational
workflow models. The cooperative workflow model, which
we proposed here, releases the burden of the user by
automatically recovering from the deadlock. We successfully
incorporated algorithm and verified.

REFERENCES
[1] Annappa, Dr.K.Chandrasekaran, K C Shet, “A Conceptual
Model of an Inter-Organizational Cooperative Workflow
“,International jouranl of Coimbatore Instistute of Information
Technology ,July 2009.