Now, when it needs a result, the server merely calls the getResult() method on the cData object.

Similarly, the server is responsible for periodically executing code to save the state of the cData object:

try {
	FileOutputStream fos =
		new FileOutputStream(f);
	ObjectOutputStream oos =
		new ObjectOutputStream(fos);
	oos.writeObject(cData);
	oos.close();
} catch (Exception e) {}

In our example, the server should execute this code each time it has called the getResult() method on the cData object. If the ClientData class had a different interface—and in particular, if it had an interface that allowed us to determine if its internal state had changed—then we could use that information instead. But that's an uncommon interface for an object to have.

It's not particularly inefficient to write the cData object out each time it's used, even if its internal state has not changed. Nonetheless, if you're worried about the extraneous I/O, you can wrap the ObjectOutputStream around a ByteArrayOutputStream instead of a FileOutputStream and in that way obtain the raw bytes of the serialized object. Then you can call the getResult() method, repeat the process to get a new set of raw bytes from the cData object, compare the new and old bytes, and only write the bytes out if they have changed.

We could build a server around this code, but there are a few remaining issues. The first is how do we define the file in which the serialized data will be held, and the second is how we must synchronize access to client data objects in a multi-threaded server. These two issues are inextricably linked, because the mechanism that we use to save the data will affect how we implement the necessary synchronization.

The issue of synchronization is particularly important because the TCP server framework that we'll eventually use runs each client connection in a separate thread. Other server environments—RMI and CORBA servers, for example—also tend to run separate clients in separate threads. We must ensure that our files will work correctly in these environments.

Let's say that we decide to use the hostname of the client that our server is servicing. This does not remove the need for synchronization: a single host can create multiple connections to our server. What we really want is a one-to-one mapping between client hostnames, ClientData objects, and files in which the ClientData objects will be saved.

The result of that mapping is that we will need to synchronize requests on some object that is common in this mapping. We can't synchronize directly on the ClientData object because that object won't exist before we read it from the file (or create it if there is no saved version of it). We'll eventually need to synchronize on the File object that is associated with each client hostname.

We need to make sure that each thread in the server uses the same File object for common hostnames. It would not be sufficient for a thread in the server to create a File object based on the client host and then lock that file object: another thread in the server could perform the same activity, and we'd end up with two separate File objects that reference the same underlying file. We'll solve that problem by keeping a global cache of File objects in the server. File objects can be obtained with this code:

static Hashtable files;
static {
	files = new Hashtable();
}
...
static synchronized File
					getFile(String host) {
	File f;
	f = (File) files.get(host);
 	if (f == null) {
		f = new File("clientData" +
				File.separator + host);
		files.put(host, f);
	}
	return f;
}

By making all access to the files hashtable static and synchronized, we ensure that there is only one File object for every hostname. Now we can synchronize on that object to ensure that multiple clients from the same host do not interfere with each other:

private void process(
			File f, OutputStream os) {
	ClientData cData = null;
	String answer;
	synchronized(f) {
		.. define cData as above ..
		answer = cData.getResult();
		os.write(answer.getBytes());
		.. save cData to f as above ..
	}
}

And that's all there is to it—even though our initial code creates a new cData object each time it runs (either by finding the cData object in the serialized file or by instantiating one), synchronizing on the File object ensures that there will only ever be one cData object for each client that is simultaneously active; a second client attempting to retrieve a cData object must wait for the first client to finish writing it out to the persistent store.

This simple technique is very useful in an environment where the server does not run continuously. Note that there is a slight chance that the server will go down in the middle of writing out the serialized data, and that the resulting data might get written out incompletely. In practice, this is not a problem: When the server attempts to read the saved data, it will get an error because the deserialization will fail; a new instance of cData will then be created.

A slightly better alternative might be to save the object to a new file, and when the file has been completely written, rename the new file to the desired name. That would mean we could always recover some state, even if the state is slightly out-of-date. There are circumstances in which that is not the desired behavior, especially in the case of a server performing caching where the state must match data that is available on the backend: in that case, we're better off with either the most recent state or no state.

There's a new feature in 1.2 that makes this all particularly attractive when used in conjunction with RMI. This new feature allows RMI servers to be started automatically by a daemon process (the RMI daemon, or rmid). When a request for the RMI server comes into a machine, rmid will automatically start the server if it is not running. If the server later exits—e.g., if it shuts itself down, or if it encounters a fatal error—then rmid will start it again when a new request comes in.

You can even arrange for the data file (or any other object) to be passed to the constructor of your RMI server by using a new class called a MarshalledObject. This class is really a wrapper class for anything that you want to use to initialize the state. In our example, that doesn't really help us, because we have a different object (the File object) for every client that contacts us. If we had a single File object that held the state for everything in the server, however, we could wrap the File object in a MarshalledObject, and that File object would be passed to the constructor of the RMI server.

Using the MarshalledObject, we'd also have to write saveState() and restoreState() methods; these methods do nothing more than serialize and deserialize the data like we did above. Of course, these methods may be arbitrarily complex in the algorithms that they use to save and restore data.