I am working on my assignment and I want to take advantage of RMI structure, so I implement the local mode this way: just instantiate an object of the implementation of the RemoteServer interface(RemoteServerImpl). The remote mode is just the normal RMI way. So the client won't know anything about the details of any method. So I can totally control the server without let the client do anything which makes sense because if I want to change any method later, I can just do it on server side. But I didn't see many people do it this way. Why not?
As long as you don't spawn any custom thread in GUI, why you need the overhead of the LockManager and the locking mechanism? When running in local mode, it is a waste of resources to instantiate the remote object by yourself. Also when you expand this application in the future to download the _Stub instances dynamically, there is no need to distribute any change made on the server to the client if you don't explicitly instantiate the remote server object at the client.
Yes. A DataServerImpl instance will be instantiated if the client is in local mode through a DataServerFactory class. I don't understand why I need LockManager. I can just implement the lock and unlock methods in Data class. And the a Data object will be in DataServerImpl class where the details of the public methods in Data can be done. Comments please!
Maybe I din't understand your design but if your DataServerImpl extends UnicastRemoteObject then your are using RMI when your client is in local mode. The assignment says we must bypass networking entirely when in local mode. Although you call the DataServerImpl methods locally, not through RMI, I think an UnicastRemoteObject instance puts itself to listen to a port so your object may be somewhat reachable from outside. (I'm new to RMI so don't trust me blindly ) You don't need a LockManager, but as the lock mechanism may be complicated and has data of its own, having a LockManager is advisable.