wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes My lock unlock 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 "My lock unlock mechanism" Watch "My lock unlock mechanism" New topic

My lock unlock mechanism

Robert Benson
Ranch Hand

Joined: Apr 04, 2010
Posts: 56
I think I need to know what needs to be done in principle,but I am not sure how to execute it. As always, your help is appreciated.

My testing revealed that my locking mechanism needs to be tweaked.

My requirement for lock is:
If the specified record is already locked by a different client, the current thread gives up the CPU
and consumes no CPU cycles until the record is unlocked.

I am trying to implement something along the lines of:

long lock(int recNo)

1 lock
2a check using a HashMap that the room is not already locked
2b If the room is already locked, then I need to lock.wait (to comply with requirement)
3 unlock

void unlock(int recNo, long roomCookie)

4 lock
5 remove room+roomCookie from HashMap
6 lock.notifyAll
7 unlock

If I do a notifyAll (6) without having issued wait (2b) then you get the IllegalMonitorStateException.

Should I make a flag,before 6, that checks if the wait was issued before doing the notifyAll or synchronize
at a higher lever?.

Regards. Robert.

SCJP 6 , OCMJD 6 ,
Roel De Nijs

Joined: Jul 19, 2004
Posts: 5212


Your lock-method will look like this (pseudo-code):
1/ check recNo in map
2a/ if it is, thread has to give up cpu (can be done by calling wait)
2b/ if it is not, generate cookie and add to map
(steps 1 + 3 in your scenario not appropriate)

Your unlock method, pseudo-code like:
1/ remove entry from map
2/ notify all waiting threads (can be done by calling notifyAll)
(steps 4 + 7 in your scenario not appropriate)

how to call the update method for example:

To call wait and notifyAll on an object, the thread needs to have to monitor on that object, otherwise you'll get the famous IllegalMonitorStateException. So in order to call wait on objectA and later on notify all threads which are in a waiting state you'll have following code:

Making your Data class thread-safe + implementing the (logical) record locking is one of the hardest (and most challenging) parts of the whole assignment. It's also one of the most important ones, so here we certainly don't provide actual code, just give you some guide lines, so you can complete this part completely on your own. It might be at first, but reward will be enormous when having a thread-safe Data class with a flawless (logical) record locking

Kind regards,

SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
Robert Benson
Ranch Hand

Joined: Apr 04, 2010
Posts: 56
Thanks Roel ,

Back on track with the locking.

Output from test script looks so much better. Just goes to show the importance of the test script for revealing errors that may otherwise have gone unnoticed.

Just one thing to query:

I removed the locks as suggested. This means that my HashMap does not have a lock and unlock before and after updates to the HashMap.
I presume its ok because the HashMap is static. Is this correct?

Roel De Nijs

Joined: Jul 19, 2004
Posts: 5212

Hi Robert,

Seems to me you don't completely understand the Data class and its requirements/functionalities to pass this certification.

1/ Your Data class must be thread-safe, so it must be capable to handle concurrent requests from different threads (clients). This has nothing to do with the lock/unlock methods from the interface you have to implement. Of course you have to make sure that the implementation of lock/unlock methods are thread-safe too So when 2 threads try to update/create/delete a different record and a 3rd thread tries to read another record, all these actions should occur concurrently without corrupting your database file or reading/updating/deleting/creating the wrong record.

2/ You have to implement also a logical record locking mechanism. Here the lock/unlock/isLocked methods come into play, together with the lockCookie. When a thread (client) wants to update/delete a record it must have the lock on that record. When a thread has a lock on a record, no other thread can change (update/delete) that record until the thread which has the lock, unlocks the record. Why you have to work with such mechanism (in an already thread-safe class) is excellently explained here in the ScjdFaq. When 2 threads try to update the same record, they will first have to try to acquire the lock on that record: one will succeed, the other one will go in the waiting state (= a must requirement). After that thread has finished its update, it will call unlock and all the waiting threads will be notified (and the other thread could get the lock and updates the record).

In conclusion: the access to your hashmap (from lock/unlock method) should be made thread-safe, but you don't use lock/unlock methods to do so.

Kind regards,
Robert Benson
Ranch Hand

Joined: Apr 04, 2010
Posts: 56
Hi Roel,
Thanks for getting back. You're right, I'm not there at the moment so I'll bury myself in one or two books and come back.

I'm making the mistake of rushing to get it out of the way. I think this is my last hurdle. Just one last push.

Thanks, Robert.
subject: My lock unlock mechanism