• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

About the opporunity of calling lock method

 
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ailsa Cape
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
reply
    Bookmark Topic Watch Topic
  • New Topic