In order to implement a factory for our bank example, we need to deal with three basic problems. The first, clearly, is actually implementing the factory. The second is adapting the existing code to use the factory. The third is revisiting some of the more esoteric functionality we implemented, such as the automatic locking mechanism in Chapter 12.
We will implement a generic factory first, in order to show the basic idea. In this simple factory, the client will request a server from the factory and tell the factory when it is no longer interested in the server.
The interface to our factory consists of two methods:
public interface BasicFactory extends Remote { public Account getAccount(String accountName) throws RemoteException; public void doneWithAccount(String accountName) throws RemoteException; }
The idea is this: because the client explicitly signals interest in a server and announces when it is done with a server, the factory will be able to directly manage the servers, shutting down those that are no longer active.
In order to implement this factory, we need to solve two basic problems:
We need to store enough information in the factory so it can create the servers when they are requested.
We need to make sure that, if the same account is simultaneously requested by two different clients, the factory doesn’t create two different servers.
The first problem is nothing new. We had to solve it before in our launch code. In ...
No credit card required