In my assigment, In case, that record is locked, to fulfill "must" requirement, I have to call wait() until the record will not be unlocked. What application should do during this waiting? Theoretically, record can be never unlocked. My opinion is, that should be better to tell the user, that record is already locked, and should to try it later, but this solution will not fulfill the "must" requirement. How did you solve this problem?
In real life situations this is what happens as you described (inform the user). According to my experience if a record is locked then you should inform the user that the record is locked, there is no need to block the user's actions until it becomes available..Furthermore imagine what would be the results in the scenario where multiple clients are trying to lock the same record. A large waiting queue will be created which is not user friendly. Of course there are cases where the clients requests some business logic if this occurs, timeout, etc...
Regarding the assignemt and my implementation I have been a bit missleaded with resource locking and I have implemented the way I have described above. My initial understanding was that resource locking is not only targeted to locking a hotel. A locked resource according to my opinion can be a hotel, the Data class itself, a data structure, etc.. I have tested my code and threads are queued and waiting for other threads to finish in order to continue regarding locks hold by the data class but if a hotel is locked i'm notifying the user.
I believe that it is entirely to the assescor's judgment of how it will be marked and how it is justified on the choices.txt. Still I haven't got my results (8th week of grading) when I'll get them i'll let you know the comments I got.
When a thread has to wait, it does nothing (consumes no cpu cycles) and is waiting until this thread is notified (by calling notify or notifyAll). Then the thread becomes runnable again (it doesn't run immediately, because the thread scheduler decides which thread may use cpu).
So you certainly have to implement waiting mechanism, otherwise you would fail because violating a must requirement. And you have to make sure every record that is locked, gets unlocked too (otherwise you might end up with a deadlock and that would mean that you will lose -a lot of- points on the locking-section). And the time a record is locked should be as short as possible.
If you expose the lock/unlock methods to the client (and create a thick/fat client) a client (that already has locked a record) can crash, and the record will be locked forever. So you could implement some timeout-mechanism (for example: if a record stays locked for more than 5 seconds it's automatically unlocked), but that's not a must requirement, so not needed (but you should mention it in choices.txt).
If you use a business service with methods like search and book (and create a thin client) it's unlikely that a record will be locked forever, unless of course your implementation is wrong (but that you have to prevent of course)
I followed the business service approach and just used the wait/notifyAll technique to ensure that must-requirement was met, didn't do anything fancy (informing user of the record already being locked).
I think that it is a very controvertible issue. If I have failed to implement a "must" requirement I believe that I would have received an automatic failure after 8 weeks. Take a look at the following thread where the same happened. There was no automatic failure but Laura Pecoraro received 0 out of 80 points for locking and in combination with some loss on the GUI part it costed her certificate.
The instructions specifies the following:
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.
Yes according to the instructions I have failed on locking a hotel record (mechanism works, threads are not waiting) BUT the server can handle multiple requests as all code is synchronized. I believe that was simply unfair for Laura to receive 0/80 since Locking is not just about locking one hotel. I mean if you have successfully locked a hotel and put threads to wait but there was a pure implementation on the data class not synchronizing threads you will receive 80/80 ?
Joined: Jan 07, 2009
In my assigment is:
It must allow the user to book a selected record, updating the database file accordingly.
Sorry,English is not my born language, as you noticed
So, can any one explain we, what the hell the Sun want to me in this "must" requirement?
Does it mean, that:
1) I have to implement usecase "book record", which locks given record and unlock will be made in the end of the usecase update,delete or calling unlock usecase
2) The lock/unlock mechanism should be implement as a part of usecases update or delete?
Joined: Sep 09, 2009
By book it means that it should allow the user to select a record and then enter a customer id representing the customer that the booking will be made for.
How you will handle lock/unlock is entirely up to what assumptions you will make. There are solution where the record is locked just before the "SAVE" button is pressed and unlocked immidiately after the transaction is completed. In my case I have chosen to lock the record when the booking process is starting and unlock it when it completes. Just remember that whatever reasonable choise you make you should justify it in your choises.txt and you will not have any problem
Joined: Jan 07, 2009
Ok, many thanks, I will lock/ulock during updating, describe all in choices.txt and will hope, that it will satisfy all requirements.
Roel De Nijs wrote:If you expose the lock/unlock methods to the client (and create a thick/fat client) a client (that already has locked a record) can crash, and the record will be locked forever. So you could implement some timeout-mechanism (for example: if a record stays locked for more than 5 seconds it's automatically unlocked), but that's not a must requirement, so not needed (but you should mention it in choices.txt).
Personally I believe a lock timeout would be an incorrect way of handling this, since you are now limiting potential business functionality in the future. You don't really know what the future requirements will be, or how wide the WAN might be that the user is operating on, but you are forcing all processes to complete within 5 seconds (while this might be an overly large number for a simple "book a record" method, it may be way too short for some administrative process that runs each night on all available records).
Note the "Personally" that precedes the opinion above - this is not to say that Roel is wrong - this is the sort of thing that design decisions documents are made for.
With both Sockets and RMI it is possible to get notification that the client has disconnected. If I were building a real-life application I would use this notification to clean up the system, possibly performing any rollback operations needed to get the database back to a clean state.
However since this is not a real-life application, I would be tempted to just note in the decisions document that such functionality is achievable, but was not implemented due to it going beyond the scope of the assignment.
I agree 100%. This is the approach I followed in my implementation. I mentioned possible ways to unlock a possible "broken" locked record but said that it is not implemented since it is not requested at the momment. As long as it is justified properly and list all of your assumptions that lead you to your design you don't have any problem..And the design of course should enable future enhancements with minimal dissruption as possible.
Andrew Monkhouse wrote:Personally I believe a lock timeout would be an incorrect way of handling this, since you are now limiting potential business functionality in the future.
Of course that's true. It was just 1 of the many possible alternatives. Because I used the thin client approach (you know, the one you think is against instructions ), I didn't have to deal with the possibility of a forever lock. So I didn't do any thinking about it and recycled the idea of the lock timeout I noticed in the ReservationsManager of Denny's DVD