Limiting the scope makes memory management easier allocated the heap
and in the libraries that come with the JDK. In this chapter, we'll discuss why threading is important in distributed programming and cover the fundamentals of using threads in Java.
11.1 More Than One Client
This has an important implication: the possibility exists that two separate clients will receive stubs for the same instance of Account (e.g., they request the same server from the registry) and then simultaneously attempt to perform banking operations on it. This could be undesirable, for example, if both clients attempt to withdraw money from the same account at the same time.
This seems like an easily solved problem. It's analogous, in the real world, to having more than one client in the bank at the same time. In the real world, the clients form a line and wait until a teller becomes available. And, at first glance, that seems like what we did with the socket-based printer server. Recall how we implemented the method that accepted print requests:
clientSocket = _serverSocket.accept( ); //
blocking call
However, this similarity is deceptive. There are two crucial differences between what happens in the bank and what we implemented. The first is that we never really implemented any sort of "next in line" functionality. That is, our socket-based printer server doesn't guarantee a first-come, first-served policy (unless the operating system does). Moreover, if a request is complex and ties
up the printer server for a significant period of time, most of the client requests will simply time out.
We can translate this scenario into computer terms:
A client makes a request on a remote server that requires the use of a currently unavailable (scarce) resource. Rather than blocking all other clients from making requests of the server, the current client's request is postponed, and other client requests are handled until the resource becomes available.
4. The server accepts the second print job but also informs the second client that the current wait is rather long, giving the client an estimate as to when the printed document will be available.
5. The client can then monitor the printer's status, sending more method calls to the printer while the printer is still printing other documents, and perhaps cancel its request.
In this scenario, network latency can cause the printer to become unavailable for long periods of time. Bob's presentation is probably quite large. And sending it over the Internet, from a dialup connection, might take a long time. If we don't insist that the printer handle simultaneous connections, then while Bob is sending the document, the printer will be idle and not accept other documents. Not only do we have the feedback problems we mentioned earlier (i.e., other clients don't have any idea when, and if, they will be able to submit documents), this is also an inefficient use of the printer.
The partial failure scenario causes a similar problem. Bob's connection could go down for a little while before the printer server realizes anything is wrong. In which case, not only does the printer server not accept documents, it no longer receives Bob's print request.
|
|---|
11.2.1 The Calling Stack
While running, a program maintains a calling stack of methods that it is currently "in." Consider the following code:
private class GetBalanceAction implements ActionListener { public void actionPerformed(ActionEvent event) { try {
getAccount( );
resetBalanceField( );
releaseAccount( );
}
.....
|
|---|
|
|---|
When an int or float is declared within a method, that variable is accessible only while that particular method is on top of the stack. Furthermore, locally scoped variables are accessible by only one particular stack frame. If a method appears twice in the calling stack, there are two distinct and independent sets of local variables.
Synchronization information.
Objects allocated on the heap, on the other hand, can be referenced from any stack frame and hence can be used as return values from method calls. But figuring out when the object is no longer useful and can be destroyed is much more difficult. Java solves this problem by making garbage collection, which is the automatic cleanup of the heap to remove objects that are no longer referenced, part of the basic language specification.
11.2.3 Threads
