Having implemented the low-level mechanics of locking in the hand-over-hand locking way following the example in the Monkhouse book, I just now realized that if I use timed waiting, the caller of lock() will not know if locking succeeded because the method's return type is void (yes I should've noticed this before
Now I wonder what I can do to make it clear to the caller whether locking succeeded or not:
- throw an runtime exception (only RecordNotFoundException being allowed from lock()) to inform the caller that he did not get the reservation?
- don't use a timeout when waiting... but then the Client could wait forever and I would have to handle this...
- interpret the isLocked() method to mean "is locked successfully by this thread" - well I think this would not be correct considering the javadoc in the Sun document.
I'd be grateful for any ideas how to handle this best ...
I have the URLyBird assignment too. The only reason that the lock() failed is when the lock() method wants lock the record that doesn't exist which that's why the method throws RecordNotFoundException.
When the particular record is being lock by other thread, the thread must wait (in my assignment, that thread must wait undefinitely).
So I think the method will never fails unless the server is down or the network cable is break.
I used plain socket so I encapsulated the class that implements the interface to the class that do the network connection to the server so in the class that do the network connection I create lock() method that throws IOException. And the GUI component that use the class that do the network connection must handle the IOException.
Hope that's help
Jeffry Kristianto Yanuar (Java Instructor) SCJP 5.0, SCJA, SCJD (UrlyBird 1.3.2) --> Waiting for the result
Joined: Jan 14, 2007
thanks a lot for your reply. In my assignment, I have:
If the specified record is already locked, the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked.
I did not read this as meaning "wait indefinitely", but it makes sense to read it like this... Do you have the same and interpret it like that?
So this would mean that apart from a network problem, if there was any other reason why the lock didn't get released, the Client would hang... I wonder how problematic this is? Also, I have not started the GUI yet, but perhaps one could implement a "cancel" button there?
Hi, I am working on B&S assignment, but I will also be implementing locks.
Isn't a good idea to put a functionality in a server to time-out the lock if one client is holding lock for more than a reasonalbe time and send that client a message(if the client is still running)-- simething like this "Your request could not be processed due to unexpted error at the server".
Please provide feedback, as I am planning the server implementation.
Jeffry Kristianto Yanuar
Joined: Oct 01, 2007
Wait undefinitly means that the thread must wait until the other thread release the lock which we don't know the precise time that the other thread needs to unlock the record number.
Using timeout implementation means the server must handle when the client lock the record and then crash before unlock the record. If the spec require you to do that, do it. If is not, it is an optional. Just make your documentation about that.
Jeffry Kristianto Yanuar (Java Instructor) SCJP 5.0, SCJA, SCJD (UrlyBird 1.3.2) --> Waiting for the result [ December 10, 2008: Message edited by: Jeffry Kristianto Yanuar ]
i interpret "If the specified record is already locked, the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked. "
when the current thread (remote client thread, local client thread....) see that the record is locked previously the current thread will gives up the cpu and consumes no cpu cycles until the record is unlocked explicitly so i don't care about the crashing or infinity waiting as the requirements don't care about it.