UrlyBird: multi-user update

[Steve Wang]

I am almost ready to upload my assignment, but felt that there may be an issue.

I have a business-tier method of bookRoom which does the following logics:
db.lock
db.update
db.unlock

Suppose I have two threads A and B trying to update DB at the same time. While thread A invokes bookRoom for client A, thread B calls bookRoom as well. So thread B goes to sleep, relinguish CPU, and such. After thread A finishes update by writing an owner ID (i.e. 111) to DB and unlocking, thread B gets lock and should be able to update DB by writing another owner ID (i.e. 222) to DB.

Now if client A tries to search all records, A will be surprised to find that he/she did not get room booked. Should I allow such scenario to happen.

I implemented a way of not allowing a "booked" record to be updated again in my GUI. When a client selects a record in JTable which has a valid owner ID, I simply disable the owner field. Only empty owner field in JTable is allowed to enable owner text field for booking. I implemented validation check for owner text field to check if user's input is digit and only 8 digits is maximally allowed. But this still may have drawback. What if a client changes his mind to cancel his booking/reservation?

However, if I allow repeated updating no matter if a record has booked as indicated by a valid owner ID, this seems undesirable also.

Please enlighten me

[YungSheng Chang]

I agree with you that repeating update should not be allowed; otherwise you will never know if your NBA final tickets are valid or not!!

The point is where you put the validation check. Some validation check is GUI implementation, and others is server side. For those real-time information, it should be server side.

Think of this scenario. A very lazy guy opens URLyBird, and he finds a room availabe in the screen. He enters his name "Lazy Guy" and goes to the movie without submit. In the time period, another guy books this record, and believes he got it. What happens when lazy guy comes back and clicks submit?
The system should not allow him to finish this transaction because he is too late!!

Think of your validation check again; which of them should be client gui, and which of them should check database. Hope this helps!!

[Steve Wang]

Thanks for suggestion. I do have a multi-tier validation check, including client-side checking and server-side checking.
If I implement what you mentioned above at server side, it does ensure that an "already-updated" record will not get overwriten (i.e. a record won't get booked twice). If this is the case, how do you handle cancellation/re-book scenario like: Client A booked a room as indicated a valid ID in DB last week, and now want to cancel the booking. We should make this record bookable again by making owner field empty.

I have read a few posts here. There are a lot of good discussions (like Peter Den Haan, Philippe Maquet etc ). Most of them handle booking in the way as you mentioned above.

In addition client-side checking, I am going to do server side checking as well. Before tryin to update a record by entering owner ID, I will check to see if this record is bookable (i.e. an empty owner field ?) No overwrite is allowed in DB. It is obvious that cancellation of a booked record is not allowed. Therefore my bookRoom method at business tier like this:
lock
if (isBookable() ) // inside isBookable(), call db.read(recNo) and check owner field
update(recNo)
unlock

Please make comments if I am working to the right direction.

[YungSheng Chang]

Just remind you that the validation check should be thorough. For me, I implement not only if the record is booked by others, also the delete flag and booking time allowed (48 hours). I think those are real-time checking and should be asking database.

I am not sure about your bookMethod since I do lock() / unlock() in read already. Therefore all other client methods do not to call lock / unlock anymore. But maybe you are implementing it the other way. Be sure to run multithread test for this before you submit. It is extremely important that locking / unlocking happens as you are expecting and no deadlock happens in SCJD.

[Steve Wang]

I was wondering why you want to use lock/unlock for inside Data's read().
My bookRoom method is a method a DataAdapter which simply wraps up Data and provides business-tier operations. In order to access to Data, client must call DataAdaper's bookRoom method, which in turn calls Data's lock, update, and unlock methods. My question is that a record cannot be double-booked.

You are right and we need to make sure no deadlock occurs. What about race condition? Have you though of the case that a client dies/crashes while this client holds lock without unlocking? There may be other rare scenarios too.