Alternative Locking Design
Amit Kr Kumar
Ranch Hand
Posts: 100
posted 14 years ago
Hi Mark, Peter, Sai, Jason and others
Pls cosider the following locking design
Peter says leave the lock and unlock methods in Data.java empty and implement everything in LockManager a reference of which will be wrapped by each Connection object.
Problem here is leaving the methods empty. Data should atleast contain the info abt which rec no habe locked and which are free, if not the logic.
Mark says let each connection manage its own lock and then forward the request to Data.java which actually store the lock records (may be using a lock manager). Problem is here that each connection is managing which lock they have taken and thus at any point of time one can not know who have locked what
Here comes my view and design on it:
1) There will be a global lock manager which will have methods:
lock(recno, connection)
unlock(recno, connection)
It will contain a hashmap of recno-connection
2) every connection will get a reference of this manager from connection factory and lock(recno) method will delegate the lock request to this lock manager's lock(recno,this) and unlock(recno, this)
3) Data.java will contain a hashset containing the list of all the rec locked. It does not know who have locked which record. No lock manager here.
just 7-8 lines of code.
The methods in Data.java will contain notify and wait logic
3) While locking :
a. the lock manager will first check whether the client requesting for lock has already taken that lock or not. If not it will forward the request to lock(recno) in Data.java where actual locking will happen using wait() and notify(). Once through with this, the lock manager will then put the recno-connection object in the hashmap
3) While unlocking :
This lock manager will first check whether the client has actually taken the lock (by checking in hashmap) and if yes it will invoke the unlock(recno) method in Data.java. After succesful invokation it will add the recno in its own hashmap.
lock(recno) and unlock(recno) in Data will just do the job of managing the threads using wait() and notify() and store the reco in its hashset.
Pls comment on this design
Regards
Amit
[ July 07, 2002: Message edited by: Amit Kr Kumar ]
Pls cosider the following locking design
Peter says leave the lock and unlock methods in Data.java empty and implement everything in LockManager a reference of which will be wrapped by each Connection object.
Problem here is leaving the methods empty. Data should atleast contain the info abt which rec no habe locked and which are free, if not the logic.
Mark says let each connection manage its own lock and then forward the request to Data.java which actually store the lock records (may be using a lock manager). Problem is here that each connection is managing which lock they have taken and thus at any point of time one can not know who have locked what
Here comes my view and design on it:
1) There will be a global lock manager which will have methods:
lock(recno, connection)
unlock(recno, connection)
It will contain a hashmap of recno-connection
2) every connection will get a reference of this manager from connection factory and lock(recno) method will delegate the lock request to this lock manager's lock(recno,this) and unlock(recno, this)
3) Data.java will contain a hashset containing the list of all the rec locked. It does not know who have locked which record. No lock manager here.
just 7-8 lines of code.
The methods in Data.java will contain notify and wait logic
3) While locking :
a. the lock manager will first check whether the client requesting for lock has already taken that lock or not. If not it will forward the request to lock(recno) in Data.java where actual locking will happen using wait() and notify(). Once through with this, the lock manager will then put the recno-connection object in the hashmap
3) While unlocking :
This lock manager will first check whether the client has actually taken the lock (by checking in hashmap) and if yes it will invoke the unlock(recno) method in Data.java. After succesful invokation it will add the recno in its own hashmap.
lock(recno) and unlock(recno) in Data will just do the job of managing the threads using wait() and notify() and store the reco in its hashset.
Pls comment on this design
Regards
Amit
[ July 07, 2002: Message edited by: Amit Kr Kumar ]
posted 14 years ago
6 of one, half a dozen of the other.
As far as what my design was, I now prefer the Peter way.
I like the LockManager, which will knwo who locked what, and control the locking. With this in mind the Data class never has to know. You can have the Data class know, like in your design, I just see that as redundant now.
Good luck, and just remember as long as you justify your design in your design.txt, I am sure you will probably be fine in your design. I can't know for sure though.
Mark
As far as what my design was, I now prefer the Peter way.
I like the LockManager, which will knwo who locked what, and control the locking. With this in mind the Data class never has to know. You can have the Data class know, like in your design, I just see that as redundant now.Good luck, and just remember as long as you justify your design in your design.txt, I am sure you will probably be fine in your design. I can't know for sure though.
Mark
John Smith
Ranch Hand
Posts: 2937
posted 14 years ago
I don't like it when I see people attaching wordds "global" and "singleton" to lock manager. What will happen when a new database is added to the application? I think you will have less points taken off if your server is designed to handle multiple databases, and therefore multiple lock managers.
Eugene.
1) There will be a global lock manager which will have methods:
I don't like it when I see people attaching wordds "global" and "singleton" to lock manager. What will happen when a new database is added to the application? I think you will have less points taken off if your server is designed to handle multiple databases, and therefore multiple lock managers.
Eugene.
| It is sorta covered in the JavaRanch Style Guide. |