Hi Henry,
1. Are we allowed to implement the locking logic in a custom LockManager class, but leave the lock/unlock method in the Data class empty?
You are allowed to implement the locking logic in a custom LockManager class.
However you will probably find that Sun's interface specifies certain functionality for the lock() and unlock() methods of the Data class. So you will not be able to leave them blank (however you could just call the appropriate methods in your LockManager class).
2. Would it be fine if I create a WeakHashMap as synchronized instead of manually synchronize accesses to the map in methods?
I'm sorry, I don't understand what you are asking.
3. I suggest that the Data class is the class accessing the DB File on server side, is that right? But I read in some thread that every client would have its Data instance? Anyone can clarify on this?
This may be part of your answer to question 4...
Some candidate's assignments require the lock() method to return a cookie which is then used in subsequent calls to the update() and unlock() methods. These people
can have a single instance of the Data class.
Other candidates interfaces require that the lock() method cannot return any value. This means that some other way of tracking ownership of locks must be devised. These candidates often create an instance of the Data class for each connected client, so that the instance of the Data class can be used to identify to the client.
Which way you do it is up to you.
By the way - there is nothing to say that the Data class must directly access the data file. It could call another class which does the low level reading / writing / caching (if you decide to have caching). As with question 1: you can have several "helper" classes below Data class if you wish. The important thing is that the client and server classes you write
must call the Data class's methods, not the helper classes methods. (This is the Facade
pattern).
4. How do we track client connections? Do we need to assign a session ID to every client connection? And how do we maintain those IDs? In another WeakHashMap?
See the answer to question 3
Regards, Andrew