FBN: can i use this design for LockManager and Data?

[Vincent Hong]

Hi!
Here is some thoughts of LockManager design and Data class modification.
Please comment!

 
public class LockManager {
    private static Map lmInstances = new HashMap();
    private Map lockMap = null;
    //other stuff needed by addLock() and removeLock() methods
    public synchronized static LockManager getInstance(String dbName) {
        if (!lmInstances.containsKey(dbName)) {
            LockManager lm = new LockManager();
            lmInstances.put(dbName, lm);
            return lm;
        } else {
            return (LockManager) lmInstances.get(dbName);
        }
    }
    private LockManager() {
        lockMap = new HashMap();
    }
    public synchronized void addLock(int recNo, Object clientId) {
        // use Map lockMap to maintain the record number and clientId pairs
        // actually, the clientId is a Data Instance here
        // so this method will be called in the Data class, 
        // by lock() method, like this:
        // LockManager lm = LockManager.getInstance(dbName);
        // lm.addLock(record, this);
    }
    public synchronized void removeLock(int recNo, Object clientId) {
        // remove the record number and its clientId from lockMap
        // will be called by Data.unlock() method
        // like this:
        // LockManager lm = LockManager.getInstance(dbName);
        // lm.removeLock(record, this);
    }
    // More Info about the Data class:
    // to use LockManager, a new field should be introduced into Data class:
    // String dbName;
    // and this dbName must be initialized and assigned a String value in
    // the constuctors of Data class:
    // Data(dbName) and Data(dbName, fieldInfo[])
    // so these two constuctors should be changed by adding a line of code:
    // this.dbName = dbName;
} 

I dont know whether the modification to Data's constructor is approved.
I just need the String dbName, and it make sense to know which data file
(or database) is currently used by this Data instance.
Hi, Max and Andrew, please comment!
Thx!

[Andrew Monkhouse]

Hi Vincent,
Welcome to JavaRanch.
I originally had a lock manager very similar to this, including the ability to manage locks for multiple tables like you do. Later I redisgned pretty much all of my server and got rid of the lock manager altogether - but that was my design, not yours. Yours is looking good so far.
As for your change within the Data class - it appears you are just storing the parameter which is already provided in the constructor. You are not actually changing the parameters of the constructor. So this will not break any existing program that might rely on a particular signature of the constructor.
As such, I think you can do this, as long as you justify it in your design document.
I am not certain why you are doing this though. I would have thought the Data class would get it's corresponding instance of the LockManager within the Data class's constructor. In which case you should not need to keep the name of the file around.
Regards, Andrew
[ September 16, 2003: Message edited by: Andrew Monkhouse ]

[Vincent Hong]

Hi, Andrew!
Thanks for your comments!

I am not certain why you are doing this though. I would have thought the Data class would get it's corresponding instance of the LockManager within the Data class's constructor. In which case you should not need to keep the name of the file around.

Yes, you are right! I have no need to add that "String dbName" field in
Data class. But still I have to add another "LockManager lockMgr" field
instead. Anyway, your suggestion is good and clear.
Originally, I thought every database or table should have a "Name" to be a
token. It's true in real world. So, any access to a database or table should
know its name. And thus the dbName should be an attribute of the accessing
class. But for FBN, it seems no need to store the name in Data class.
Here I've got another question which puzzled me for a few days.
Would you please be kind to clear me again?
As in my post above, the design is based on this: (I choosed RMI)
Each remote database client has its own Data instance.
(That is somewhat alike Max's design, which also keeps a Data instance for
each remote client.)
Here comes my question,
If each client has its own Data instance, many "synchronized" modifiers
of other methods seems to be no use according to Data class difinition.
But my design is restricted to having that Data instance for "clientId"
purpose. Now I am in a delimma.
Andrew and Max, and anyone else,
Would you please help me out?
Thx in advance!

[Andrew Monkhouse]

Hi Vincent,
No matter which assignment you do, you will find areas where you have to compromise something.
With FBNS, I found the biggest issue is what you are asking about now. Do you modify Data such that it can track users within the class, or do you track ownership of locks outside the class. Either option can work.
You are right, if you have multiple instances of Data class, then the synchronization should not be at method level, so you will need to change this. Also you want to think about the add() method - do you need to make changes to it in order for it to still work in a multi user environment.
Regards, Andrew

[Vincent Hong]

Hi! Andrew,
I really appreciate your words!!

You are right, if you have multiple instances of Data class, then the synchronization should not be at method level, so you will need to change this. Also you want to think about the add() method - do you need to make changes to it in order for it to still work in a multi user environment.

Yes, I know what should I do now!
Thanks again!
Vincent