A deadlock is a situation where two or more processes are unable to proceed because each is waiting for the other processes to proceed. Deadlocks are an undesirable side effect of the concurrency control provided by event isolation within a collaboration. See the Collaboration Development Guide for more information on event isolation.
Figure 16 illustrates a deadlock between two active collaboration groups resulting from the following sequence of events:
At this point, all collaborations are unable to move forward.
Figure 16. Deadlock between collaboration groups
This section covers the following topics:
"Detecting a collaboration deadlock"
"Detecting group collaboration deadlocks"
"Fixing a collaboration deadlock"
You can configure the IBM WebSphere ICS system to either perform or not perform deadlock detection:
System Manager does not provide the ability to set the DEADLOCK_DETECTOR_CHECK configuration parameter. Instead, to set this configuration parameter, you must edit the InterchangeSystem.cfg file and change the parameter's value in this file. Because the InterchangeSystem.cfg file is an .xml file, the following lines should exist in this file to define the DEADLOCK_DETECTOR_CHECK parameter:
<tns:name>DEADLOCK_DETECTOR_CHECK</tns:name>
<tns:value xml:space="preserve">false</tns:name>
To restore deadlock detection, change the false value to true.
You can check for a group collaboration deadlock in one of the following ways:
A window appears with the following message:
The following diagnostic tests were run on this collaboration:
This message if followed by one of the following results:
Error 11135: Activation of collaboration collaboration_name group could cause a potential deadlock with one or more existing collaboration groups, and is therefore disallowed.
This error warns only of a potential deadlock situation. The informational messages preceding error 11135 identify the active collaboration groups that potentially enter into a deadlock.
If the WebSphere ICS system encounters a deadlock, you must shut down and restart InterChange Server. First, gracefully shut down all other collaborations, then shut down the server immediately.
Upon system restart, a hung collaboration that caused the deadlock automatically starts and resubscribes to all of the business objects it supports. The business objects that caused the collaborations to enter into a deadlock are redelivered. At this time, the collaborations should not enter into another deadlock because deadlocks are timing dependent. It is unlikely that you will have the exact same server load and isolation sequencing that you had when your system encountered the deadlock.
After restarting the system, shut down the collaborations involved and rebind the ports so that this does not occur again.
You can prevent collaboration deadlocks by configuring the deadlock retry settings in the Database tab of server configuration screen in System Manager. To configure the deadlock retry mechanism, do the following: