Java Reference
In-Depth Information
before releasing the logical record lock? In such a case, the record will be locked for all time—
no other client will ever be able to lock the record.
Once again there are many possible solutions, some of which include the following:
•
Having a thinner client (where the client just calls a
rentDVD
method on the server, and
the server calls both the
reserveDVD
and
releaseDVD
methods) will bypass the problem
totally. The lock should never become totally unavailable. We recommend you refer
back to the section on fat/thin clients earlier in this chapter to see the ramifications of
this (and possibly join in the discussions on JavaRanch on this topic).
•
If we have a socket network solution, then the server thread servicing the client will
receive an exception when the client disconnects. If that thread keeps track of which
locks have been granted, then it could release them if it receives this exception.
•
If we have a server factory, with unique
DvdDatabase
objects as our client identifiers,
we could store the reservation data in a
WeakHashMap
with the client identifier as the
key. When the client disconnects, the
DvdDatabase
for that client will (eventually) be
garbage collected and the lock will be automatically removed from the
WeakHashMap
.
In this case, we would probably want a separate thread monitoring the
WeakHashMap
so that it can notify any waiting threads that a reservation has been cleared.
•
If we have a server factory with unique workers per RMI client, we could have the
worker implement
java.rmi.server.Unreferenced
. The
unreferenced
method from
this interface will be called sometime after the RMI client disconnects. If the worker
instance keeps track of which locks have been granted, then it could release them if
unreferenced
is called.
•
Ignore the problem. Again, seriously—is it a requirement of your assignment? Is there a
possibility 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 clients dying (if anything). How-
ever, if your instructions do not mention this at all, you will have to decide for yourself
whether you want to handle the possibility of locks never being released. Some of the questions
you might like to ask include the following: Is it more professional to handle disconnected
clients? Does handling disconnected clients add unnecessary complexity to the code?
Whatever you decide, keep in mind that this is a design decision that you might like to
document.
Discussion Point: Multiple Notification Objects
Consider what will happen if 100 threads are all waiting to reserve different records. When a
thread releases its lock on any one record, it will call
lockReleased.signal
, and
all 100 threads
will be notified that a lock has been released, so all 100 threads will attempt to regain the
lock
mutex and check whether it is the record that they are interested in that was released—and
potentially the released record was not of interest to any of them! So there would be a sudden
burst of CPU activity each time a record is released, potentially lowering productivity on the
server each time.
