must lock wait?

[Bram Pramono]

Hi ranchers,

I've been busy with my SCJD assignment for a few months now. I'm almost finished and just need to document everything but while documenting, I wonder if my locking mechanism will be acceptable or not.

I understand that the assignment stated that a thread must wait when a record is locked until the locked is released. I wanted to implement this at the beginning, but it just doesn't make sense for me. This is why I think the waiting doesnt make sense:

Imagine that 2 users want to access the same record and user 1 has the lock first. So the user 2 has to wait. Now user 1 has updated the size of the room, or/and the smoking possibility for the room for example. Then user 1 is done with his action, he releases the lock on the record. Then come user 2. He gets the key and he wants to book the record. He was looking for a room with size 2 with no smoking possibility. But this was changed by user 1. So why would he now book this room? Same thing as user 1 delete record and user 2 waits for it, user 2 will only get RecordNotFoundException. So why bother waiting?

Next to that how will you show the GUI that someone else is busy with the record, and how long he must wait for the locked record?

I've been looking in the forum, and it seems everyone thinks that lock mechanism has to wait, but I just cant agree about it. Please give me some input for this problem.

Thank you.

Cheers,

Bram

[Roel De Nijs]

Hi Bram,

Of course lock must wait: it is a must requirement. not doing it will cause you to automatic fail (it happened to Laura because she throw a RuntimeException instead of waiting)

in pseudo-code I use following algorithm to book my hotel room:

lock record: if record is not found anymore, throw exception

read record

check if room is still available: available => book it (update record), not available => throw exception

unlock record

You give an example of a user updating the size of a room, but a more obvious example is a room that was being booked previously by another client. So you have to check if the room is still available, because otherwise you would override someone else's booking and that will result in some complaints (2 or even more customers showing up at the same hotel, all booked successfully the same room).

You could extend the above pseudo-code and do some kind of check to see if the record you read (after acquiring the lock) is still exactly the same as the record client wants to book (and if not, throw a StaleDataException or something like that)

Hope it helps clear your doubts.
Kind regards,
Roel

[Bram Pramono]

Hi Roel,

thanks for the reply. I have read the forum thread about Laura failing the exam. But she said that she didn't understand the statement of "no CPU cycle consumed", so I assumed that she did not write on her decision.txt about this problem. I, on the other hand, am 100% aware of the situation. I can explain why I took this decision. Is it that bad that a must requirement is not implemented, even if i can explain the specific reason?

Also my locking mechanisme assignment forced me to use lock cookie as an authentication key for the lock. This means that a client trying to update or delete a record need lock this first then update or delete. So my GUI for client work as follow :
1. A client tries to book a room. Click on "Book" button -> check if record is locked, if not -> lock record -> GUI gives popup window to fill in consumerID
2. The client fill in the customerID and press enter. Check if input valid, if yes -> send customerID and update record -> unlock record

So the scenario I imagine is that the client will always lock at start before starting to edit or delete. The editing and deleting will take a few seconds or minutes before it is committed. If this happens, and I let other clients, who want to access the same record, wait until the first client finished. It will take a long time for the other clients to access the same record. This is actually the main reason why I feel strongly that waiting is not an option.

I'm not being stubborn here, but I just want to make clear of my situation and I would like to know whether the "must" requirements cannot be avoided with explanation on decision.txt.

Cheers,

Bram

PS: Example of escaping "must" requirement I found in the forum is that many people implement 3-tier architecture instead of 2-tier

[K. Tsang]

Bram Pramono wrote:Also my locking mechanisme assignment forced me to use lock cookie as an authentication key for the lock. This means that a client trying to update or delete a record need lock this first then update or delete. So my GUI for client work as follow :
1. A client tries to book a room. Click on "Book" button -> check if record is locked, if not -> lock record -> GUI gives popup window to fill in consumerID
2. The client fill in the customerID and press enter. Check if input valid, if yes -> send customerID and update record -> unlock record

So the scenario I imagine is that the client will always lock at start before starting to edit or delete. The editing and deleting will take a few seconds or minutes before it is committed. If this happens, and I let other clients, who want to access the same record, wait until the first client finished. It will take a long time for the other clients to access the same record. This is actually the main reason why I feel strongly that waiting is not an option.

PS: Example of escaping "must" requirement I found in the forum is that many people implement 3-tier architecture instead of 2-tier

Hi Bram,

Let me say a few words with you current approach to locking. From what I understand, you lock the record when the book button is clicked on the client side "before" the popup window display? Now it indeed seems good ensuring single thread behavior. However, if client A books record 1 (and DID NOT close the popup), client B tries to book record 1... client B will wait. In this situation, forever because client A popup window still open (hence that record 1 is still locked).

Now instead of locking when the book window is open, lock the record when the user click OK in the popup window (the instance the data is sent to the server). Now depending on 2-tier or 3-tier architecture you use, you will definitely need to do checking just before the data is updated. Checking has that record been modified before you try to update (meaning someone else booked the room already).

About implementing 3-tier architecture, the must locking requirement is not neglected. Everyone somewhere need to call lock->update/delete->unlock in their code. Whether it's in the server layer (3-tier) or in the client layer (2-tier). So no escaping.

You may want to check out a similar topic when I was doing locking. https://coderanch.com/t/437586/Developer-Certification-SCJD/certification/Wait-lock-method

[Roel De Nijs]

Hi Bram,

Can't agree more with my good buddy K. Tsang: you should keep the time a record is locked as short as possible. In your case a record could be locked a whole day (and so it is more likely other clients will have to wait and wait and wait). If you have a short-period lock (like K. illustrated in his post, and like i did too: start the book process after you get all information from the client), it's nearly impossible clients will have to wait for a very long time.

If you don't gonna wait when a record is already locked, what are you gonna do instead? Throwing an exception (like Laura did)? And another question: if user hits the book button, you check if the record is locked. if it's not, a popup is opened. But what happens if the record is already locked? Does your GUI freezes or can the user select another room to book?

Avoiding a "must" requirement with an explanation in choices.txt is kind of risky: if they have an automated program to test the "musts", they just run the program and see if it gives the expected output (otherwise fail you) without reading anything. If you want to do a favor for the scjd-community you can be the ginny pig: take the risk, submit your assignment and see if you can pass with avoiding a "must" requirement by documenting it I would certainly not have taken that risk (a resubmission fee is just too expensive). In addition I think your approach will certainly result in some point loss, because you always try to keep the locking time as short as possible...

Kind regards,
Roel

[Gert-Jan den Besten]

This ("must" requirements) is one of the topics the instructions.html is very clear about:

Important Note About Automatic Failure

Where this document uses the word "must" an absolute requirement is being described. If you fail to adhere to such a requirement, your assignment will be failed automatically, and without further evaluation. It is therefore imperative that you pay close attention to any statement using the word "must" in this document. Portions of your submission will be analyzed by software; where a specific spelling or structure is required, even a slight deviation could result in automatic failure.