Ive been trying to understand just how logical record locking is supposed to prevent two uers/clients from booking the same record, hence overwriting each other. Below is some background info about my assignment after which I'll lay out the scenario which Im trying to figure out.
Signature and comments for lock method: // Locks a record so that it can only be updated or deleted by this client.
// Returned value is a cookie that must be used when the record is unlocked,
// updated, or deleted. If the specified record is already locked by a different
// client, the current thread gives up the CPU and consumes no CPU cycles until
// the record is unlocked.
public long lock(int recNo) throws RecordNotFoundException;
Signature for unlock method: // Releases the lock on a record. Cookie must be the cookie
// returned when the record was locked; otherwise throws SecurityException.
public void unlock(int recNo, long cookie)
throws RecordNotFoundException, SecurityException;
Problem scenario (without logical record locking) Consider two clients A and B.
1.) Client A retrieves all records and this is diplayed on the screen in the JTable
2.) Client B retrieves all records and this is diplayed on the screen in the JTable
3.)Client A selects record 1 and client B also selects record 1 (this record's owner field is empty so both clients can tell from there that the record is available)
4.) Client A attempts to book record 1 and in so doing calls the update method (directly or indirectly, yet to decide) in Data class. I intend to synchronize access to the update method so that when client A's thread enters the update method no other thread can enter until client A releases the Data object's lock.
5.) Similarly, Client B attempts to book record 1 but cannot proceed because client A has not finished executing the synchronized update method in the Data class. So Client B will block until Client A finishes the method and releases the lock (note that in the update method, i'll check whether the record is still available before updating the record)
6.) After Client A finishes the update method and releases the Data object's lock, Client B attempts to continue and enters the synchronized update method to perform its booking. However, when it checks whether the record is still available, it finds that it is no longer available and so it can't book it. So the thread returns and the client is notified that the record is no longer available.
My question: The whole point of logical record locking is to prevent two or more clients from booking the same record and hence overwriting eachother's booking. However, from the scenario I have above, I dont see how two clients can overwrite eachother's booking because of the check i'll introduce in my update method to see whether the record is still available. Is there something Im missing here?
Your update method is not supposed to check if the record is still available! Your update method should just update all fields and that's it.
The contract of the update method is updates each field of the record and not "update each field if the record is still available". Your Data class should not contain any business logic, so it can be easily re-used for the management of a similar customer database file (code reusability)
Spot on guys, that makes a whole lotta sense to me now. However, the Monkhouse book and the link in your last post talks about locking the record before checking for availability. This throws up another question in my head:
After locking a record successfully, the client program still has to check whether the record is available, despite the fact that the record's owner field is empty in the JTable (after a find operation meaning its available)?
Olu Shiyan wrote:After locking a record successfully, the client program still has to check whether the record is available, despite the fact that the record's owner field is empty in the JTable (after a find operation meaning its available)?
From a business logic layer perspective a data record can be locked. Once it is locked the owner field could have the "" empty String or have "12345678" and up to you to decide what action to do according to the purpose of that business logic operation (maybe
you can throw an RoomAlreadyBooked exception if you are booking).
It is up to you to make some assumptions of the semantics of each case to what that case means.
You also need to do this check because your Database server is supporting multiple clients and it could have been booked by another
client between the time you saw it as "" in the GUI and the time you hit the Book button.
Now from a Presentation layer perspective (Swing GUI, web page, etc.) you can make some assumptions for the data records
in your JTable to disable the book operation when the owner has a value different than the "" empty String.