Originally posted by Miles Toliver:
I have a question/observation about the locking mechanism for my URLyBird assignment that I would like to get some of your opinions on. At this point, I have made two assumptions for my design that I think are common to many of the designs for others SCJD projects.
1) A record lock is not required for records reads. I don't mean that one client will be allowed to read a record while another client is updating the same record, but a client will not need to obtain a logical lock from the "Lock Manager" to read a record. This will help improve concurrency but will allow dirty reads. However, I think there is an overall consensus that dirty reads are okay for this project.
2) There will be no dynamic notification process to update all connected client after a record is updates. In other words, in the records displayed on a client's GUI are "stale" they will not know until they attempt to update (i.e. book) a record and receive some sort of ModifiedRecordException (or something similar).
Given these assumptions (which I think many others have made) we can draw some conclusions. First, the only time a logical lock is granted is when a client is going to update a record. Second, any client that attempts to update a record based on data that is not the latest, persistent data for that record will not be able to successfully complete there update (they will first have to reread or at least acknowledge the updated data).
To make a long story short (too late , here is my question. When attempting to obtain a logical lock, we are supposed to block if that record is currently locked by another client. What is the point of this? If the client that currently holds the lock is presumably updating the record, then the client waiting for the lock will not be able to complete their update once the lock is available (because the data will not be different). In other words, if the lock is not avaiable, the only result for the client requesting the lock will be the ModifiedRecordException mentioned earlier. What is the point of blocking for the lock to become available just to get some sort of exceptional condition.
I realize this question is somewhat theoretical since the specification list waiting for an available lock as a "must" requirement. I was just interested in getting your thoughts on this and see if I am missing something?
Originally posted by Miles Toliver:
Thanks for the reply. You make some very good points.
For starters, I definitely agree that the DB interface class provided is not a very good interface and is not how I would have designed it. For this reason, I am planning to have a URLyBirdServer class that resides on the server side and is a go-between class for the GUI and the DB class. The client GUI would invoke methods in this class such as book(), which would get the logical lock, update the record, and unlock it. Client only makes a single remote call (hence the thin client part). It would be relatively easy and straightforward to have logic in this class to detect whether the update to be made is coming from stale data or not.
I am not sure I totally agree that updates should be made regardless of the state of the data. For the URLyBird project, the only "update" currently possible from the limited GUI would be booking an empty room. Surely an update cannot go through to book a room that has since been booked by another client (hence overwriting the original, and true, booking).
Thanks for the feeback.
Agreed....brings me back to my original observation: what is the point of blocking in the lock method? (aside from the fact that we have to do it as a project requirement). Not trying to be difficult, but rather I want to make sure I am not missing anythin