Should RemoteData object created using Singelton pattern

[Jeff Shen]

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

[friso dejonge]

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.

[Michael Morris]

 

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.

/*
* DataFactory
*
* Version 1.0
*
* 07-12-2002
*
* Copyright � 2002 Fly By Night Services �
*/
package suncertify.db;
import java.util.*;
import java.io.*;
/**
* This singleton class provides access to <code>Data</code> objects. It
* guarantees only one instance of <code>Data</code> per database file.
*
* @author Michael Morris
* @version 1.0 07-12-2002
* @see Data
*/
public class DataFactory {
/**
* A <code>Map</code> implementaion that holds all opened <code>Data</code>
* objects indexed by their path names.
*/
private Map dataInstances = new HashMap();
/**
* The sole (singleton) instance of this.
*/
private static DataFactory instance;
/**
* The sole constructor. Since it is not publically accessible, a <code>
* DataFactory</code> object may only be instantiated by calling the static
* <code>getInstance</code> method. To remain a singleton, subclasses of
* this should not make their constructors publically available.
*/
protected DataFactory() {}
/**
* Retrieves the single instance of <code>DataFactory</code>, creating it
* if necessary.
*
* @return the <code>DataFactory</code> singleton object
*/
public static DataFactory getInstance() {
if (instance == null) {
instance = new DataFactory();
}
return instance;
}
/**
* Creates and returns the <code>Data</code> object for the given database
* and schema.
*
* @param dbname the <code>String</code> path for the database file
* @param fields the <code>FieldInfo[]</code> list of fields for the
* schema of this database
* @return the <code>Data</code> object for this file
* @throws IOException If the specified file cannot be created
*/
public synchronized Data newData(String dbname, FieldInfo[] fields)
throws IOException {
Data db = new Data(dbname, fields);
dataInstances.put(dbname, db);
return db;
}
/**
* Retrieves the <code>Data</code> object for the given database, opening
* it if necessary.
*
* @param dbname the <code>String</code> path for the database file
* @return the <code>Data</code> object for this file
* @throws IOException If the specified file cannot be opened
*/
public synchronized Data open(String dbname) throws IOException {
Data db = (Data) dataInstances.get(dbname);
if (db == null) {
try {
DBFileCheck.checkDBFile(dbname);
db = new Data(dbname);
} catch (IOException exc) {
throw new InvalidDataFileException(exc.getMessage());
}
dataInstances.put(dbname, db);
}
return db;
}
/**
* Closes the given database
*
* @param dbname the <code>String</code> path for the database file
*/
public synchronized void close(String dbname) {
Data db = (Data) dataInstances.get(dbname);
if (db != null) {
db.close();
dataInstances.remove(dbname);
}
}
}

Hope this helps,
Michael Morris

[friso dejonge]

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

[Michael Morris]

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

[Jeff Shen]

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

[Michael Morris]

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