Server-evaluation models Ch a pt e r 7

When you think about it, remote iterators, like the instances of CallbackClient_DialogImpl in the previous section, are one-shot servers. They encapsulate an answer to a single request and are rarely put into a naming service.

21.3.1.1 Server-evaluation models

If a server returns a result via a remote iterator, the implementers of the server need to make a policy decision: does the method use full evaluation, background evaluation, or lazy evaluation? In full evaluation, the server computes the entire answer to the client request as part of handling the original remote method invocation. In background evaluation, the server computes the first group of responses and creates the remote iterator. It then sends a response to the client and continues figuring out the full answer. In lazy evaluation, the server computes the first group of responses and creates the remote iterator. It then stops computing and waits for further client requests. When it receives requests for data it does not have, it then continues to compute until it has all the needed data. In terms of coding difficulty, theres often not a substantial difference between these approaches. Generally speaking, background evaluation is the hardest to implement. However, once you have an implementation using full evaluation, the conversion to either a lazy or a background evaluation strategy is usually straightforward. This is, in fact, whats usually done. The first pass at implementation uses a full evaluation strategy. Later on, if there are performance problems, the code is changed to background evaluation. Lazy evaluation is rarely used in this context. The reasons for doing so are also straightforward. Full evaluation can take a long time before returning the first responses; the server waits until it knows the entire answer before responding at all. Background evaluation, in comparison, returns very quickly. Its also a more efficient use of resources: part of the answer is sent while the rest of the answer is computed. In addition, the client can do things with the partial answer, such as display the results in a JTable , while the server is processing. Lazy evaluation returns from the initial request just as quickly as background evaluation does. However, it conserves server resources by postponing further processing until the client explicitly asks for the information. This slows the remote iterato since computation has to occur within each request for information. Full and background evaluation have very similar semantics. They attempt to return the answer to a remote method invocation at the time the remote method invocation was made. Lazy evaluation is a little different. For example, suppose that the client makes a query of the form, Show me all accounts with a balance under 1,000 and gets back a remote interator. The end user looks at some of the information and then realizes, Its time for lunch. Ill look at the rest of this after lunch. What happens when the end user resumes work an hour later? In the case of full and background evaluation, the server has already computed a response, which is presumably sitting inside a data structure. When the end user resumes looking at the data, she is looking at the answer to her query, as of the time the query was made. But in the case of lazy evaluation, the server needs to compute the response when the end user starts 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