After all these troubles, I am actually leaning towards NOT providing support for multiple databases. That is, in local mode, the user will just browse the database file, and in remote mode, the client will specify the server DNS and port only (no references to a specific database).
But that will make it hard to justify the server design choices, as adding the new databases in the future will require significant coding changes.
There are some more coding convention guides on the net. Follow the newer vesion. The one on Sun s site is pretty old.
If you use Data, and your locking is implemented in that class, then the locking will happen in local mode. That's what we are trying to avoid.
except that the methods of Data will have to be defined in two places, actually four places, if you count the inteface: data interface, Data, LocalDataImpl, RemoteDataImpl.
I like this design because it allows locking to be done without modifying the signature of either methods.
What abt the following statement in lock(int) of Data.java
lockManager.lock(myRecord, Thread.currentThread));
In Local mode we can delegate the action to Data.java.
However in Network Mode the Connection object will directly call Lock Manager as given below
lockManager.lock(myRecord, this);
In network mode the response will not be delegated to Data.java