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..
( and author)
That sounds ok to me, though I think a formal lockmanager is somewhat overkill. I suggest that you write a multithreaded test client, and see how it all holds up.
The Sun Certified Java Developer Exam with J2SE 1.4
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
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.
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
[ October 17, 2002: Message edited by: St�phane Weber ]