As far as I understand it, the user specifies the name and location of the datafile in 'local' mode and specifies only the hostname/ip and port number in 'remote' mode.
Ok, not if you see your Data instance as a database being available 24-7.
But if you are connecting to a table/view , you may want to think about lazy initialising your Data instances , also.
Similarly, if you are handling multiple databases , the database schemas, will also be encapsulated in the Connection object as parameters. A standard solution repeated in many database packages.....
That's wrong. How else will the user know why his application failed?
How are you handling the error message, i.e. how does creating data and lock manager instances in advance help in this case ?
I am confused why you are creating Data and LockManager instances in advance. Is it for Connection pooling , which I think I am right in saying is outside the requirements ?
Thanks for the feel-good support on leaning towards handling of dead client locks being a system requirement. There is now a third option to be considered , do nothing about dead client locks .
This is a new slant on the use of the LockManager class.
If you search for threads on connection on this forum , you'll find lots of discussions supporting the following :
Each client creates it's own Connection object, with a connect(table name) method and it's own LockManager object with a reference to a shared HashMap/WeakHashMap for storing the unique client identifiers.
I suspect it's semantics again, and what you call LockManager , I call HashMap/WeakHashMap i.e the Collection class for storing the identifiers.
Assigning responsibilities in the right place?
Starting the server, should just start the server registry. The Client Connection class is responsible for connecting to the data , the LockManager is responsible for acquiring and releasing locks on the data and uses a HashMap/WeakHashMap to achieve this.
Looking at your code snippet , I don't think you should have data.getInstances and LockManager.getInstances in your code.
This thread shows you are OK with having both a daemon thread and using unreferenced to handle dead client locks as long as you have given a good reason (i.e. understand the mechanics behind it).
I hope they'll accept my reasoning that this is a system requirement and not an application requirement. By system I mean the RMI distributed garbage collection sub-system.
Okay, I'll come back to what I think are two design options after doing some reading up, or if someone jumps in and kindly volunteers to agree/disagree.
It could be the wording again.
All DataService implementations (client connections) WILL share the same Data but each client connection has it's own LockManager instance but shares the HashSet or whatever it is you store your unique client identifier in.
Just semantics, but the two could be implemented very differently.
That is 1: use Unreferenced and let the "system" decide when to release the lock for the dead client.
2: Don't specify a lease period and the "application" decides when to release the lock.
Ah , a dead lock rather than deadlock (LOL).
That makes more sense.
But if you are using Unreferenced, do you need this daemon thread?