aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes URLyBird locking mechanism Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "URLyBird locking mechanism" Watch "URLyBird locking mechanism" New topic
Author

URLyBird locking mechanism

Jos Pasen
Greenhorn

Joined: Dec 15, 2010
Posts: 5
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!
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5278
    
  13

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!


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5278
    
  13

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

Joined: Dec 15, 2010
Posts: 5
Thanks for the input, Roel. I was worried I might overlooked something simple.
Himai Minh
Ranch Hand

Joined: Jul 29, 2012
Posts: 758
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
Ranch Hand

Joined: Jul 29, 2012
Posts: 758

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

Joined: Dec 15, 2010
Posts: 5
Thanks for the input, Himai. Greatly appreciated!
 
jQuery in Action, 2nd edition
 
subject: URLyBird locking mechanism