Should RemoteData object created using Singelton pattern

I have a question about the RemoteData.
My RemoteData extends the UniqueCastObject and implement the DataInterface. To implement the RemoteData I have used the Data object. The Code is like following
DataInterface data = null;
try {
// Create a RemoteData object
data = new RemoteData(dbName);
//LocateRegistry.createRegistry( Integer.parseInt(port) );
LocateRegistry.createRegistry( port );
} catch (RemoteException remoteException) {
System.err.println(
"Failure during object export to RMI: " +
remoteException);
} catch (IOException ioException){
System.err.println(
"Failure during object export to RMI: " +
ioException);
}
This means that for each client the RMI create a new Object and open the database. My quesion is that should I use singelton pattern on the RMI server so that it only generate one instance of the database for all client?
Regards,
Jeff

why use a singleton ? I am not saying it is wrong, but could you achieve the same with a static data object, so there still is only one instance ? When you create that static instance, or use it, just check whether it is not null.
Again i am not saying it is wrong, just find the answer to the above question and maybe add it to the design decisions document.

Originally posted by Jeff Shen:
My quesion is that should I use singelton pattern on the RMI server so that it only generate one instance of the database for all client?

No. Just make sure you only create one for this implementation. Try thinking of Data as a single database table. If the server is later scaled to offer multiple tables, using a singleton will kill the whole effort.

Originally posted by friso dejonge:
... but could you achieve the same with a static data object, so there still is only one instance ? When you create that static instance, or use it, just check whether it is not null.

The same thing applies here. Now forevermore you can only have one database table in the server.
Below is a legitimate use of a singleton for this assignment. I used this in mine. I got the idea from Peter den Haan who was having the same argument with me that I am with you now.

Hope this helps,
Michael Morris

michael,
i am not trying to argue over what the best or only way of doing this is. I just want to have him think about the implications of doing it one way over the other.
cheers,
friso

Hi Friso,

i am not trying to argue over what the best or only way of doing this is. I just want to have him think about the implications of doing it one way over the other.

I know you're not and I did not mean to sound as though I were rebuking you. But I would like to dissuade anyone from making Data or LockManager a singleton as seems to be the trend among candidates. It just handcuffs future developers from extending the server.
Michael Morris

Thanks so much for the useful help. Only one thing I don't understand is that Michael mentioned even the LockManager should not be singleton, what I'm thinking is the LockManager must be sigleton, would you advice me more regarding this issue.
Regards,
Jeff

Hi Jeff,
For the same reason that Data is not. If you can have multiple Data objects representing different tables then you must have a different LockManager for each table. So making LockManager a singleton causes the same maintainance problem as making Data a singleton.
Michael Morris