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
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.
Joined: Apr 04, 2010
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.