Java Reference
In-Depth Information
Discussion Point: Deadlock Handling
Deadlocks occur when a thread is blocked forever, waiting for a condition that cannot occur.
Chapter 4 discusses deadlock handling from a threading perspective, but the same issues
apply at an application logic level as well. Consider what would happen if two clients were
both trying to get logical locks on the same two records, but in different orders, as shown in
the following example:
•
Client A gets a logical lock on record 1.
•
Client B gets a logical lock on record 2.
•
Client A attempts to get a logical lock on record 2.
•
Client B attempts to get a logical lock on record 1.
Our
reserveDVD
method times out after 5 seconds. But if both client A and client B imme-
diately retried to get the lock, the result would be the same as if we didn't have a timeout: both
threads would effectively be deadlocked.
There are many solutions to prevent deadlocks, among them:
•
Don't allow a client to ever lock more than one record at a time. If they cannot lock
multiple records, then you cannot get a logical deadlock.
•
Only allow clients to lock records in numerical order. Under these rules, client B would
not be allowed to attempt to lock record 1 in our previous example, and would have to
give up the lock on record 2 at some point, which would allow client A to continue.
•
Have a dedicated mechanism for tracking that locks are owned and which locks are in
contention. Each time that a new lock goes into contention, this mechanism would be
checked to see that a deadlock will not occur, and if it will, the lock is cancelled. This is
the most complex of the possible solutions, but the code required is mostly recursive
and can be written simply with a little thought.
•
Ignore the problem. Seriously—is it a requirement of your assignment? Is there a possi-
bility that attempting to handle this problem could result in you making a mistake that
might cost you marks? Do you feel that this is out of scope for the assignment?
Once again, we are going to recommend that you read the instructions you received from
Sun very carefully to determine what you need to do about deadlock handling (if anything).
However, if your instructions do not mention this at all, you will have to decide for yourself
whether you want to handle deadlocks. Some of the questions you might like to ask include
the following: Is it more professional to have deadlock handling? Does deadlock handling add
unnecessary complexity to the code? Can you handle deadlocks with the exceptions you are
allowed to throw?
Whatever you decide, this is a design decision that you might like to document.
Discussion Point: Handling Client Crashes
Earlier in this chapter, we discussed the potential for having thick clients, where the client will
be responsible for obtaining a logical record lock and later releasing it. But what happens if
the client crashes (or is just shut down) sometime after requesting a logical record lock but
