File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes logical locking and potential for concurrent thread access 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 "logical locking and potential for concurrent thread access" Watch "logical locking and potential for concurrent thread access" New topic
Author

logical locking and potential for concurrent thread access

Colin Duggan
Ranch Hand

Joined: Feb 23, 2008
Posts: 41
I'm working on the Urlybird assignment and in the middle of implementing my locking solution. I have a Data class which implements the Sun interface. This Data class then uses two singletons, DatabaseManager and LockManager. In my Data class i have update and delete methods, i use a reentrant lock in these to prevent multiple thread access at the same time.

My question is about the logical lock. In order to call one of update or delete in my Data class i first need to make a call to lock(recNo) in the Data class to see if the record has already been locked by another thread. Do i need a another reentrant lock for my lock method to ensure no more than one thread can access it at a time?

Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2268
    
    3

Howdy, Duggan! Welcome to our JavaRanch, champ!

My question is about the logical lock. In order to call one of update or delete in my Data class i first need to make a call to lock(recNo) in the Data class to see if the record has already been locked by another thread. Do i need a another reentrant lock for my lock method to ensure no more than one thread can access it at a time?


You mean, you have a reentrant lock in your Data class, and you think it might be necessary to have another reentrant lock in your DatabaseManager class? If that's the case, then no. In order to test your locking mechanism, you may look at the tests I proposed for it.

And another comment, is your Data class a singleton? If so, then your DatabaseManager and LockManager objects don't have to be singletons.


Cheers, Bob "John Lennon" Perillo
SCJP, SCWCD, SCJD, SCBCD - Daileon: A Tool for Enabling Domain Annotations
Colin Duggan
Ranch Hand

Joined: Feb 23, 2008
Posts: 41
Cheers!

Might go with that suggestion. Right now my Data class is not singleton, it has reentrant lock which is static. Inside my DatabaseManager i synchronize my update/delete/find/get/create methods.

Yep i have a reentrant lock in my Data class not the DatabaseManager class. I was wondering if i needed to create another reentrant lock in my Data class which would only be used by threads getting the logical lock?

The reasons i was considering adding another lock; a) i want the logical lock method to be thread safe and b) i don't want threads holding the reentrant lock for the logical lock method holding up other threads(who may already have successfully locked the record they want to update) from getting the reentrant lock for the update and delete methods.

Thanks for the test, will use. How do you ensure that no more than one thread can logical lock a record?
Colin Duggan
Ranch Hand

Joined: Feb 23, 2008
Posts: 41
ok, i was doing too much in the Data class , i have moved the Reentrant lock into the class which calls the methods on the interface and this allows me to obtain the logical lock and then decide whether to wait or continue with update or delete all using same reentrant lock.
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2268
    
    3

Howdy, Duggan!

i have moved the Reentrant lock into the class which calls the methods on the interface...


You mean, now you have the ReentrantLock in the LockManager class? Or the Data class? It's just that I think it would make more sense to have it in the LockManager class.
Colin Duggan
Ranch Hand

Joined: Feb 23, 2008
Posts: 41

Thanks Roberto,
I have my reentrant lock in my LockManager class. I have implemented the lock and unlock methods however i would like to satisfy the requirement that waiting threads will not consume any CPU cycles until the desired resource becomes available.

I would like to keep track of all waiting threads per record in a hashmap. Then, when unlock is called for a record, I would like to notify this map and pull only the next thread(calling getFirst in my LinkedList). However with this approach when i call notify i don't have control of the thread that is started. I then use this thread to get the next waiting thread from my LinkedList so i end up waisting CPU cycles.

Does this violate the requirement?
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2268
    
    3

Howdy, Colin!

Champ, although I admire your will to keep everything in its place and use the exact amount of processing, I think you may be introducing unnecessary complexity. The idea is just to put the Threads in waiting state if they want to lock a record that is already locked. When the Thread that has locked the record unlocks it, it notifies all waiting Threads that were waiting for this resource to become free. The VM should decide who gets the next chance to lock this record.

It's pretty simple: in your lock() method, you just verify if the record is already locked. If it isn't, then you just verify if it is still a valid record and lock it. If it is locked, then, in a while loop, you wait for it to become available again. Trying to do things as simple as possible is also a very important requirement for successfully achieving this certification.
Colin Duggan
Ranch Hand

Joined: Feb 23, 2008
Posts: 41
cheers, and believe me im trying to keep it simple

if you verify if the record exists inside the lock method then will you be adding unnecessary coupling between the LockManager class and the class that called it? Could you just lock the record without validating it exists and then check later, before you make changes to the database?

Alot of people on the forum have got the 44/80 score for the locking section. Maybe ignoring the CPU cycles could be part of that??
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2268
    
    3

Howdy, Colin!

if you verify if the record exists inside the lock method then will you be adding unnecessary coupling between the LockManager class and the class that called it?


Well champ, it is indeed sort of hard to tell as I can't see your code... but I think this verification will have to be done in the LockManager class, with the help of the class that keeps (or accesses) the valid records.

Could you just lock the record without validating it exists and then check later, before you make changes to the database?


Hum... I discourage that. The best thing to do is to verify if the record is valid when locking it. If it isn't valid, then you can throw RecordNotFoundException.

Alot of people on the forum have got the 44/80 score for the locking section. Maybe ignoring the CPU cycles could be part of that??


Well, I think that, since the "consuming no CPU cycles" part is a must, ignoring it would lead to automatic failure.
Colin Duggan
Ranch Hand

Joined: Feb 23, 2008
Posts: 41
One more question Roberto, are you preventing threads from reading a particular record while another may be updating?

I am considering using a RentrantReadWriteLock. This will allow multiple reads at the same time but not updates, and on the other hand single update and no reads. The only problem of course is performance.
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2268
    
    3

Howdy, Colin!

One more question Roberto, are you preventing threads from reading a particular record while another may be updating?


Hum... no. I simply perform the search, getting the int array that is returned by the Data class' search method. After that, I get each of them and build a Map<Integer, Room> and return it. So records may get updated between searching and reading. But I didn't face this as a problem. I think a problem would be if the application allowed deletion of records.

I am considering using a RentrantReadWriteLock. This will allow multiple reads at the same time but not updates, and on the other hand single update and no reads. The only problem of course is performance.


Well champ, performance is not a problem since it is not a requirement. So, I'd say that if your solution works properly, then go for it!
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: logical locking and potential for concurrent thread access