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

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!

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!