Avoiding deadlocks
A deadlock is a stalemate that results when two sessions are
waiting for each other to release locked resources. When distributed
applications begin taking advantage of the capabilities of shared
objects and server push technology, deadlocks can sometimes occur.
What causes deadlocks
When a client connects to a server, it gets its own session
on the server. That session provides the client with a separate
context in which to execute. Because the client does not need to
compete for system resources with other clients, deadlock situations
do not arise. However, when clients share objects on the server
and/or pass object references back and forth, the situation
is very different. In this case, contention for objects can result
in deadlocks.
Deadlocks can occur when client sessions pass object references
to other clients or when shared object sessions make synchronous
calls to other sessions.
Example
The following example illustrates how deadlocks occur. Client
2 has made a function call to Session 2, which in turn has made
a function call to Session 3. Client 1 has made a function call
to Session 1 and is blocked trying to make a function call to Session
2, which is in the process of handling Client 2’s request.
In this example, the sessions could be either client sessions
on separate servers, or sessions associated with shared objects
on a single server. If these are client sessions, then assume the
following preconditions:
- Client 1 has a reference
to an object in Session 2, which it passes to Session 1. - Client 2 has a reference to an object in Session
3, which it passes to Session 2. - Session 2 has a reference to an object in Session
1, which it passes to Session 3.

If Session 3 tries to call Session 1, which is in the process
of handling Client 1’s request, a deadlock occurs:

How to avoid deadlocks
Here are some general guidelines that will help you avoid
deadlock situations:
- Do not make synchronous
calls between shared object sessions. - Use asynchronous calls when pushing messages from
the server to the client. - Do not pass references to client session objects
to sessions other than the client or a shared object.
You can perform a synchronous server push from the client
session on the server back to the corresponding client. However,
if you do this, the client session will not be able to perform other
processing until the client has responded. If the client is busy,
the client session on the server will have to wait to get a response.