*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes About the opporunity of calling lock method Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "About the opporunity of calling lock method " Watch "About the opporunity of calling lock method " New topic
Author

About the opporunity of calling lock method

Ailsa Cape
Ranch Hand

Joined: Aug 10, 2005
Posts: 92
Hi, everyone!

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?

Thanks in advance!
Regards, Ailsa Cape
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Hi Ailsa,

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).

Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Ailsa Cape
Ranch Hand

Joined: Aug 10, 2005
Posts: 92
Hi, Andrew

Thank you again!

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?

Thanks in advance!
Best Regards, Ailsa Cape
Kuno Snaglers
Greenhorn

Joined: Sep 28, 2005
Posts: 6
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
Ailsa Cape
Ranch Hand

Joined: Aug 10, 2005
Posts: 92
Hi, Kuno

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
Kuno Snaglers
Greenhorn

Joined: Sep 28, 2005
Posts: 6
Hi Ailsa,

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.

Kuno
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: About the opporunity of calling lock method
 
Similar Threads
How can a deadlock occur in a thin client?
lock and unlock
GUI display & booking questions
no claimers for this one...very sad....
NX: Using SwingUtilties.InvokeAndWait method in GUI