• 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

URLyBird locking mechanism

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi guys,

Yet another thread about the locking mechanism. I've been reading through countless of threads but I'm still confused about a couple of things.

In my implementation I cache the contents of the database file to a HashMap.

I am now trying to implement my locking mechanism but I'm still not sure about a couple of things:

In several threads I read that people are locking and unlocking in de delete()- and book()-methods. For the delete()-method this seems fine but I can only see this working for the book()-method if the client specifies the userID for the booking right away. I had the following in mind (while also taking in account that the same flow could be used for an update action):

1) The user has the view with the table with all records in front of him, he decides he want to book record number 20 and selects the record and presses the book-button.
2) A detailview is opened, using the selected recordID the correct record is fetched from my cache using the read()-method and the record's field values are filled in. All of them are not editable except for the 'userID'-field.
3) User enters a name in the 'userID' field and clicks on the Save-button.
4) The record is updated.

How would this work if the locking mechanism is executed in the book()-method (in my case the method executed when the user clicks on the Save-button in my detailview)? Also by doing so multiple users would still be able to select this record and click on the Book-button in the table view, getting the detailview.

As far as I can see this may not happen and as soon as the user opens the detailview the record must be locked (step 1) so other users cannot open it. The record will then remain locked until finally step 4 has been reached. However by doing so other questions arise, like let's say the first user wants to book record 20, the detailview opens and the user goes away for 2 minutes, rendering the record locked. Another user wants to book record 20, the record is locked so the user's thread get put to sleep until it becomes available. Does this mean that the user's GUI will hang until the first user either cancels the detailview or clicks save (judging by the javadoc of the lock()-method: "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 wouldn't let the Thread of the second user wait until the record becomes available, instead I would present a message that the record is in use at the moment so that user 2 can go on with his business instead of hanging until user 1 is done.

Am I overlooking something?


Input would be greatly appreciated!
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Quick reply while waiting for movie to begin

1. Always keep time a record is locked as short as possible

2. Update & delete methods should only update or delete record, not lock/unlock. The book method will lock record, perform needed business logic and finally unlock record.

Now it's time for iron man 3!
 
Roel De Nijs
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The scenario to book a record is spot on! That's exactly how i implemented it. My booking logic has a few additional steps than lock/update/unlock to prevent double bookings.
Why would you think it would not work?
 
Jos Pasen
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the input, Roel. I was worried I might overlooked something simple.
 
Bartender
Posts: 2418
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can take a look at Roberto Perillo's Test class for reference.

The key implementation is:
lock (record_Number);
update (record_Number);
unlock(record_Number);

When one user clicks your save button, the record_Number (eg record 20 ) is locked, updated and unlocked.
When a second user attempts to lock record 20, this user needs to wait until the record 20 has been successfully unlocked.
So, in your lock method, provide a wait method and in your unlock method , provide your notifyAll method.
 
Himai Minh
Bartender
Posts: 2418
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Does this mean that the user's GUI will hang until the first user either cancels the detailview or clicks save (judging by the javadoc of the lock()-method: "If the specified record is already locked, the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked")?



This idea is good, but you can try something simple. "Simplicity is the key" in terms of the exam.
The second user's GUI may not need to hang. If the first user has already booked the record 20, the second user will get a "RecordAlreadyBooked" exception from the screen.
If the first user is booking the record, the second user will wait. That will satisfied "the current thread gives up the CPU and consumes no CPU cycle until the record is unlocked."

Hint:
Create two threads that shares the same object, sharedRecord.
Use code similar to this for your synchronized lock method
Use this for your synchronized unlock method

This is the key thing your exam grader is looking for. If you miss this or if you get a deadlock, you will fail the whole exam according to Roberto.

Helpful Reference : http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/locks/Condition.html and Terry Camergo and Andrew Monkhouse's SCJD 5.0 study guide, published by Apress. (This book is old, but helpful.)
Roberto also provides you guys a paper that talks about the exam.
 
Jos Pasen
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the input, Himai. Greatly appreciated!
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic