Iterators on the client side

looking at the data again. If the answer changed in the interim, its not clear what the iterator should do.

21.3.1.2 Iterators on the client side

If a server returns an answer via an interator, the client has to make repeated requests for the data. The usual way of doing this, called background downloading, uses a second thread whose sole responsibility is getting information from the server in small chunks. That is, the client pursues the following strategy: 1. The original request, which receives a partial answer, is initiated from an original thread the Swing event thread. In many applications, this occurs in response to a user action e.g., clicking a button. 2. After receiving the partial answer, the original thread creates a second thread, which continues to download information. 3. After creating the second thread, the original thread continues to process the partial answer. In many client applications, this amounts to displaying the partial answer in a GUI for an end user to look at. 4. Periodically, the second thread updates the original thread with more information. In many client applications, this boils down to creating instances of a class that implements Runnable and dropping them off in Swings event queue. This strategy is useful for two reasons. First, it minimizes the amount of time the client spends waiting. The first batch of data arrives quickly, and the rest follows in short order. The client spends almost no time waiting. Second, it minimizes the amount of server resources a client demands. If youve decided to pursue either a full or lazy evaluation strategy, then, once the answer is computed, theres no reason to store it on the server. Its static information to which no other client has access. Logically, it belongs with the client application. How Many Threads Is That? Its worth stopping and counting just how many threads are involved in handling a remote iterator in a typical application. The client has two threads: the thread that makes the initial request and the thread that handles the background downloading. The server, on the other hand, uses three threads. The first is the thread that listens on a server socket to establish the original connection. The second is the thread that listens on the original connection and handles the initial response to the request including creating the remote iterator. Since sockets and their associated threads are reused, the thread that handles the initial request will probably also be the thread that handles the remote method invocations that the iterator receives. And, finally, the server has a thread that performs the background evaluation. Of these five threads, four deal with devices. On the client side, one deals with the screen and one reads data off a socket. On the server side, two deal with sockets and one performs computations. The nice thing about this arrangement is that all of these threads can be simultaneously active. Since most of them pursue individual tasks that can be impeded by external factors for example, network congestion can cause some of the threads to slow down, the fact that the threads are mostly independent means were taking full adva ntage of our available resources. Viewed this way, iterators arent just a convenient way to deliver partial responses to an impatient end user. Theyre also a way to write more efficient code. By breaking the response down to a set of small, individually handled chunks, weve come close to maximizing system throughput.

21.3.2 Implementing Background Downloading on the Client Side