My Lock Design !

[Vikas Sood]

Hi Mark,
I am defining here my design logic for my LockManager kindly comment on it
I am having a seperate LockManager class inside the suncertify.server package.
This is a singleton class,with main four methods
such as lock, unlock , lockAll & unlockAll.I make use of HashedMap as lockHandler:
lockHandler=(HashMap)Collections.synchronizedMap(new HashMap());
I also have controll variable for database level lock : lockStatus
lock(int recno,Object clientid){
Step 1)check for database level lock record no. if not databse level lock and record not equla -1 ~
check for this record being locked ,if not lock it.notifyAll()
Step2)check if the lock requested is for -1 that is database level lock.
call lockAll()
else
Step3) wait for the databse level lock to be released,when the lock is released call lock(recno,clientid) again.
}
unlock(int recno,Object clientid){
Step1)check that unlock is not for whole database and then match the client id with one in hashmap,if true remove lock.
notifyAll()
Step2)call unlockAll()
}
lockAll(Object clientid){
wait for all locks to be removed from lockHanler.
set lockStatus=true;
Put something in lockHandler for this client.
notifyAll()
}
unlockAll(Object clientid){
clear lockhandler.
setlockStatus=false.
notifyAll()
}
Kindly comment on my lock design.
VikasSood
[ October 28, 2002: Message edited by: Vikas Sood ]

[Vikas Sood]

Hi friends,
Kindly please go through my design above ,I am at the finishing stages of my locking design,and as u know locking is for 30 marks i am a bit worried about doing something wrong.Please comment on my design and feel free to give ur inputs.
VikasSood

[Griffith]

Vikas:
My design for LockManager is quite similar to yours, with a seperate class and interface within suncerify.db.
One difference: I elected to synchronize the lock/unlock methods within my LockManager class, instead of synchronizing the HashMap itself. By implemented the LockManager as a sungleton, I'm guaranteeing only one instance per JVM.
I'm not sure of the advantages of either approach ...

[Vikas Sood]

Hi Grifith,

Originally posted by Griffith:
Vikas:
My design for LockManager is quite similar to yours, with a seperate class and interface within suncerify.db.
One difference: I elected to synchronize the lock/unlock methods within my LockManager class, instead of synchronizing the HashMap itself. By implemented the LockManager as a sungleton, I'm guaranteeing only one instance per JVM.
I'm not sure of the advantages of either approach ...

I have some questions for u regarding ur design.
1)Why are u keeping ur lockmanager in db package,i think we need to put it in the server as we are going to use the locking mechanism only in remote mode,i think we should put this class in server package only.
2)Why are u synchronizing the lock-unlock methods as a whole ? i think if we synchronise them as a whole then it means that multiple clients using lockmanager implemented as singleton will have to wait top acuire a lock on lockManager object before being able to get a lock on a record,while in my case they get to enter the method and get to do locking in a more appropriate way .
And also we all know that it is always better to have a small synchronized block blocking clients access to some resources instead of having a whole method being blocked.There still might be some operations in a method which do not require any synchronization and can be carried out without an object lock.
Hope it helps.
VikasSood

[Griffith]

Vikas:
I put my LockManager in the db package for a couple of reasons: I felt that record-locking was integral to any database, and wanted these functions in the core package. Local connections can ignore lock/unlock. Also, lock() and unlock() are public methods which must be visbile on our remote GUI -- according to the requirements. Since they cannot be removed from the Data class, I was inclined to give them an implemention there and to have the locking functionality within the same package.
You make a good case for synchronizing on the HashMap, instead of synchronizng methods -- I will need to revisit this ...