[Andrew's Book] Deadlock, Client Crashes & Multiple Notification

[Shan Jun Hao]

I was reading on Andrew's SCJD Exam with JSE5. I came across these 3 sections:

Deadlock Handling

Client Crashes

Multiple Notification Objects

My assignment did not mention particularly the need to handle the 3 situations mentioned above.

For deadlock handling and multiple notification objects, I believe these 2 are beyond the scope of the requirements, therefore I choose not to handle both issues. (I am welcome to alternate suggesstions... pls =D)

But I believe I have a problem with client crashes. I don't understand what Andrew meant on the following:

Having a thinner client (where the client just calls a rentDVD method on the server, and the server calls both the reserveDVD and releaseDVD methods) will bypass the problem totally. The lock should never become totally unavailable.

Can someone kindly illustrate to me?

[Daniel Bryant]

Hi Shan,

I'm working on URLyBird 1.2.1, and I agree with you in that Deadlock detection is out of the scope - I will mention in my choices.txt how it could be implemented (i.e. what classes should be modified etc)

I believe with client crashes Andrew is referring to the following scenario (which is possible with my spec, but maybe not yours depending on which assignment you are working on)

Scenario
Client A wants to book a hotel room. This consists of reading, locking, updating and then releasing the lock on the record. The difference between a thick and thin client is [i]where[\i] the methods that perform these operations are called from.

[b]Thick client Assumptions[\b]
CRUD operations (read(), update(), delete() etc) and locking (lock(), unlock() ) methods are exposed on the server-side API

Problem scenario

Client A connects to the server
Client A locks record 1 (with the intention to update the details)
Client A crashes (without releasing the lock)
Client B attempts to lock record 1, but never can because the lock will never be released by Client A

[b]Thin client Assumptions[\b]
CRUD operations and locking methods are NOT exposed on server-side API. Instead the API exposes business operation methods only, such as bookRoom()

The previous problem scenario can not occur in this case, because instead of the client performing multiple method calls (lock, update, unlock) with the potential of crashing at any point in between the calls, the client now simply calls bookRoom() and this [i]server-side[\i] method calls the lock, update, and unlock methods.

If the client crashes during these method calls it doesn't matter, as the server-side business method executes independently of the client and performs all the locking and unlocking, and so will never leave the record in an undertermined state.

Regarding the multiple notification - I'm not too sure what you mean by this. If it means using the new locking API and multiple condition objects to ensure a thread is only notified if the record it is waiting for is released, then yes I have done this. I have seen on this board that it appears Sun doesn't penalise you if you don't do this, but with Andrew's book it really is quite easy to add, and I like to play safe when it comes to "must" requirements in the specs

I hope this helps,

Daniel
[ August 08, 2006: Message edited by: Daniel Bryant ]

[Shan Jun Hao]

Regarding the multiple notification - I'm not too sure what you mean by this. If it means using the new locking API and multiple condition objects to ensure a thread is only notified if the record it is waiting for is released, then yes I have done this. I have seen on this board that it appears Sun doesn't penalise you if you don't do this, but with Andrew's book it really is quite easy to add, and I like to play safe when it comes to "must" requirements in the specs

Yup... I am refering to lets say you have 1000 threads waiting and when a thread releases, there will be a sudden burst of CPU activity. I guess I will give some thoughts about whether if I want to implement this eventually.

[Shan Jun Hao]

Hi Daniel,

After much consideration and reading my instruction:

Locking

Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above. You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server. Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available.

I decided not to implement this. However, I will just document the possibilities of future enhancements.