In my design, the lock method was called when the user presses the Reserve button. I found a weakness in it. In network mode, if a user wants to reserve a record, the program first check if the record is being locked by someone else. If isLocked method returns ture, the program give the user a message dialog to query him/her if he/she wants to wait. I found if the user receives this dialog, he/she will never reserve the record and only see the record's owner column in the table changed by other person finally. Is the business logic right?
If the lock method was called when the user inputs the owner ID, other persons who want to update the same record receive the message dialog and wait. Maybe the client who currently owns the lock of the record doesn't want to update it and chooses another record, then unlock the record and so in the waiting queue, there would be a client who really updates the record when he/she gets the lock. But to do so, it could generate another quesion. What if the user who owns the lock of the record, after he/she inputs half of the owner ID, the person goes out for a long time, then the record will be locked for a long time. It seems unacceptable.
Do you think what time is the best time to call the lock method?
Personally I have my doubts about the value of the isLocked method. Since many candidates don't even get that method in their instructions, it appears that Sun consider that you can complete the assignment without it.
As for the "locked for too long a period" - I think you are going beyond the scope of the assignment. There is nothing in the instructions that I read that indicates that you need to concern yourself with this (but there is a warning against going outside of scope).
Do you mean I should call the lock method when a user selects one row in the JTable? I think if the instructions have allowed me to update another field or for the future enhancement, say size field, then my design would have been reasonable. For example, the first person who owns a lock of a specific record might have updated the size field. When the second person gets the lock, he/she might have updated the owner field and both of them could have succeeded. Can I use this specification in the design choice file to confirm my design?
As for the mentioned reasons of timeouts, I designed the client with implicit locking. Therfore, my client interface doens't provide any 'lock' or 'isLocked'-method. I just implemented an 'update', 'find', ..methods. These methods garantee atomic write access by using the 'lock' and 'unlock' of the Data Interface, but hide the locking from the client. With my design choice I run into trouble when multiple users like to update the same record at time. I found a workaround to reread the record and compare it with the record from the GUI-table. If these records don't equal, I show a message that the reccord is outdated. Keep in mind: There is still a little risk that both users success at the same time, however, it simplifies the implementation much. I hope (;-}) that an explicit lock handling on the client is out of the assignement scope. I think, that's what Ailsa ment in his last reply ...? I'm right, Ailsa?
Thanks for your reply
Joined: Aug 10, 2005
Sorry for coming late. Yesterday, I bought the voucher for the essay exam.
Do you mean you called the lock method in the server side? If so, you can find some hints in one of Andrew's great post.
I think if you lock the record after the user press the Book or Reserve button, there will be needless to set the time limitation to a locked record, right?
Regards, Ailsa Cape
Joined: Sep 28, 2005
I just put down all the buiness logic to the server. I do following scenario in my book method:
# lock # reread record from the db # test if booked already # update customer id # unlock
I may also put the customer id verfication and 48h roule into the server.