Java Reference
In-Depth Information
How you identify your lock owner depends on what your instructions state, and possibly
on how you develop your network server. We will offer some suggestions in the following sec-
tions, but you will have to determine for yourself what will work for your specific instructions.
Using a Token to Identify the Lock Owner
If we can return a token from the lock method to the client requesting the logical lock, then we
can mandate that the client must use that token when performing other operations, including
when they release the logical lock.
The token itself (also referred to as a “cookie” or a “magic cookie”) is something that our
class would use to identify the owner of the logical lock. As such, it does not have to be a
meaningful object, since the client does not need to do anything with this token other than
store it for use when calling other methods. In fact, it is probably better that this token be ran-
dom, since if the token has some meaning then the unscrupulous programmer might be able
to guess it and still unlock our records.
However, our interface requires that our lock method return a Boolean and the
releaseDVD
method does not allow us to insert a token either, so this is unfortunately not
an option for us.
Using the Thread to Identify the Lock Owner
If we opt to use sockets for our network interface, we will have total control over the threads
used by each client. We will create a new thread when the client connects to the server, so we
can use the thread identifier as a proxy for the client identifier.
When doing this, we would simply store the thread identification with the record identi-
fier at the time we logically lock the record. Then, whenever the client attempts to do anything
that needs the lock, we can compare the current thread identifier with the stored value; if they
match, then we allow the operation.
This saves the client worrying about storing and reusing a token, but it will only work for
our stand-alone client and for a network solution based on sockets. If our network solution
uses Remote Method Invocation (RMI), this won't work.
Using a Class Instance to Identify the Lock Owner
The RMI specification states that there are no guarantees about which threads will be used for
any given remote method. This means that the following scenario is possible according to the
specification:
•
Client A uses thread 1 to logically lock a record.
•
Client B uses thread 1 to attempt to logically lock the same record; it waits for the
logical lock to be released.
•
Client A uses thread 2 to logically release the record.
•
Client B uses thread 1 to logically release the record.
More complex scenarios are also possible. Listing 5-1 shows an example of this problem.
