Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

HashMap, lock + unlock

 
Max Tomlinson
Ranch Hand
Posts: 365
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a question re: using a HashMap to lock access to my db records. Since I will have to synchronize the Map externally (as items will be added to and deleted from the HashMap) won't that lock the entire HashMap and prevent record-level locking?
Map m = Collections.synchronizedMap(new HashMap(etc.));

thanks,
Max
 
Trevor Dunn
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would not think so. Since if a thread calls add on the HashMap it will get the lock, and any other thread will just wait unitll the lock is released then go in.
Trevor
 
Max Tomlinson
Ranch Hand
Posts: 365
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Trevor-
Thanks, but do you mean it will lock at the method level and not at the Map level? That's not what I get from reading the Sun API:
"Note that this implementation is not synchronized. If multiple threads access this map concurrently, and at least one of the threads modifies the map structurally, it must be synchronized externally. (A structural modification is any operation that adds or deletes one or more mappings; merely changing the value associated with a key that an instance already contains is not a structural modification.) This is typically accomplished by synchronizing on some object that naturally encapsulates the map. If no such object exists, the map should be "wrapped" using the Collections.synchronizedMap method. This is best done at creation time, to prevent accidental unsynchronized access to the map."
What I want to do is lock at the method level, so that when a client wants to get a particular record index (Map item) it will then lock, but not lock out the other record items.
 
Sajid Raza
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You might consider not using the synchronized instance and try using synchronized blocks as you choose. In some methods you could:
<code>
syncrholized(lockMap) {
// do lock
}
</code>
An in other places you could:
<code>
ClientID clientid = lockMap.get(key);
// To simply check on things.
</code>
I think you're right in being apprehensive about locking the locks data structure during non-critical access. However, you are going to have to lock the map whenever you add or delete. I don't think there's any way around it.
[This message has been edited by Sajid Raza (edited July 28, 2001).]
 
Max Tomlinson
Ranch Hand
Posts: 365
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sajid-
Thanks. This is the area I'm struggling with. I realize I have to lock the whole map for add/delete and that's no problem. But I STILL don't see how the locking you suggested locks at the key level only. It's seems your code snippet is pseudocode? Still syncronizing at the map level, right? How can I do the equivalent of 'lockmap.get(key)' and lock THAT key only.
thanks,
Max
 
Trevor Dunn
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok I think I understand. You want to know how to implement fine-frained locking. WHere you lock on the element in the Hashmap and not on the whole Hashmap. Check out this link, it does exactly what youeant but using Arrays.
http://developer.java.sun.com/developer/TechTips/2000/tt0328.html
However, I must add, and you will find when you read it, the code is fairly complicated and while the savings in speed is amazing, It is probably beyond the scope of this assignment and I doubt will get you any extra points.
Trevor
 
Trevor Dunn
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Trevor Dunn:
Ok I think I understand. You want to know how to implement fine-frained locking. WHere you lock on the element in the Hashmap and not on the whole Hashmap. Check out this link, it does exactly what you want but using Arrays.
http://developer.java.sun.com/developer/TechTips/2000/tt0328.html
However, I must add, and you will find when you read it, the code is fairly complicated and while the savings in speed is amazing, It is probably beyond the scope of this assignment and I doubt will get you any extra points.
Trevor

 
Max Tomlinson
Ranch Hand
Posts: 365
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Trevor-
Thanks for the link. But I am still confuesd (maybe it's a state of mind). Are you saying that record-level locking is not part of the assignment? The FlyByNight instructions say to implement "record locking" and for a record of -1, lock the whole DB. Any ideas on how else I am to do this?
Max
 
Sajid Raza
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Honestly, I don't see the need for such fine-grained locking. After all, as long as you can lock a record against non-owner modification does it really matter whether the actual process of obtaining the lock was synchronized on the HashMap (or lock-recording data structure)? If the lock/unlock methods are the only place where serialized access to the data structure occurs would it have such an affect on performance?
As long as other clients' threads can read and search while a client is trying to lock a record is acceptable. If you're going to allow for concurrent lock operations that work properly, I think you'll be doing much more work than the assignment calls for.
 
Trevor Dunn
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Max I think you are a little confused.
When the assignment states record level locking, think locking on the database. So for instance you could follow something along the lines of this
1. Client requests lock on record 10
2. Check to see if record 10 is in a list of locks, if it is not
then proceed with locking code, otherwise wait
3. Then when thread is finished notify other threads that you are fininshed with record 10, so they can then attempt to continue with their operation if they are waiting on record 10
If you synchronize the above operations then you are still providing record level locking by only letting one thread at at a time gain access to certain record but you will be synchronizing on the whole locked record list.
In case of the -1 for the whole db all you have to do is wait untill their are no locked records and maybe set a boolean which you can check each time a thread requests a lock. How you implement it is up to you. I hope I was clear enough to help you see the difference.
 
Max Tomlinson
Ranch Hand
Posts: 365
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Trevor-
Thanks. I think I was initially thinking of true record locking (e.g. RDBMS row level locking) and couldn't see how that would work with a flat file which is essentially being controlled by one process. Now I know what to do here.
thanks again,
Max
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic