Our
implementation of printDocument( ) in Chapter 4 was
simple: we accepted the request. The return value
of the printDocument(
) method simply told the client whether
the request had been successfully received. In
essence, we treated printDocument( ) as an ordinary remote
method. As a result, our client application wasn’t
very user-friendly. The user doesn’t simply want
to know that the request was received by the
printer. The user wants to know the status of the
document as it prints, and when the document is
finally done printing, the user wants to know
about that as well.
The reason we wrote such a bad implementation was because it was in Chapter 4, and we were more concerned about introducing the basics of RMI than making fine distinctions between types of remote requests. Moreover, printer-type methods force the client to become a multithreaded application and therefore couldn’t be handled before Chapter 11 and Chapter 12. Now that we know that RMI uses multiple threads, and now that we understand synchronization, we’re ready to handle printer-type methods.
You may think that we can
simply use the following strategy to implement
printDocument(
):
Accept all requests.
Synchronize the methods in the
implementation of Printer so that most requests block and
wait for the printer to become available.
The methods involved in the implementation
of Printer can
now return the result of the print job.
And, indeed, the code for this is simple; it boils ...
No credit card required