This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
Hi, I wanted to make sure that I have implemented the locks properly. I have a lock manager class that is a singleton. Lock manager has 2 public methods( lock and unlock). The lock manager also has a hashmap to keep track of all the records that are currently locked. The records are stored in the hashmap with the record-number as its key. Please give me more suggestions on lock manager.. Thanks, Sumesh
Hi, The record number is indeed the key IMO. The client ID cannot, as you could have a same client own several locks at the same time. Then you would want to have several entries with the same key. (Or then you have to use a list in the value attribute of your map, which makes things more difficult). On the other way, if you just have your record number be the key, all you need is to put a reference to your client (client ID, ...) as value of the map. Hope this helps Stephane
Joined: Mar 19, 2002
Hi Stephane, I agree what u say. If i have clientID as key and lets assume two request comes to the server at the same time to book different records then being ClientID is the key unnecesserly it has to wait, Where its not needed in case of having recordNo as key. Is it wright to do locking using HashSet which uses recNo alone. thanks, rameshkumar
Joined: Mar 07, 2002
1. Don't forget that HashSet is not synchronized : (extract from the Java API for class HashSet)
Note that this implementation is not synchronized. If multiple threads access a set concurrently, and at least one of the threads modifies the set, it must be synchronized externally. This is typically accomplished by synchronizing on some object that naturally encapsulates the set. If no such object exists, the set should be "wrapped" using the Collections.synchronizedSet method. This is best done at creation time, to prevent accidental unsynchronized access to the HashSet instance: Set s = Collections.synchronizedSet(new HashSet(...));
So you better synchronize your LockManager if you want to be sure that the HashSet will remain consistent with concurrent accesses. 2. It is ok to have only record number, if you find a way to be sure you grant unlocks only to those who locked ... Personnally I used a clientId to keep track of the owner of a lock. But some threads in JavaRanch discuss the other possibility.
Hope this helps Stephane [ October 17, 2002: Message edited by: St�phane Weber ]