Java Reference
In-Depth Information
■
Caution
Before deciding whether to build a thin or a thick client for your submission, carefully read the
instructions you downloaded from the Sun site to determine whether there are any requirements you must
adhere to. There have been many discussions about this on JavaRanch (
http://www.javaranch.com
)
regarding this topic (one, started by one of the authors, had 133 views put forward), and you are welcome
to join in the discussions there.
But consider the same scenario with logical record locking:
•
Client A logically locks the DVD record for
Office Space
.
•
Client B attempts to logically lock the DVD record for
Office Space
; however, it cannot
do so until client A releases the logical lock. Client B must now wait for client A to finish.
•
Client A retrieves the DVD record for
Office Space
.
•
Client A verifies that there is one copy of the DVD still in stock.
•
Client A rents the DVD.
•
Client A releases the logical lock for the DVD record for
Office Space
.
•
Client B logically locks the DVD record for
Office Space
.
•
Client B retrieves the DVD record for
Office Space
.
•
Client B finds that there are no more copies of the DVD in stock.
•
Client B releases the logical lock on
Office Space
and (hopefully) goes off to find some
other DVD to rent.
One of the major advantages of logical record locking is that it allows a greater
concurrency. It can also work across a network, so we can use the power of our thick clients.
Discussion Point: Identifying the Owner of the Lock
It is rarely good enough to simply have a way of logically reserving a record and releasing the
reservation. You typically need some way of identifying which client has reserved the record,
so that only they can release it.
An example from real life might help explain why we need this. Imagine if you rang
the theater and reserved the last seat for a show. But then some other person turned up at the
theater and claimed that they had reserved the seat. If the theater does not have some way of
identifying who reserved the seat, you could lose your seat.
Likewise, if we don't identify the owner of a lock, an unscrupulous programmer could
write a program in such a way that if they have not received a lock within a certain amount of
time, they will just unlock the record anyway.
