Cache Stubs to Remote Servers
One of the practices in Section 6.2 was entitled “Always Use a Naming Service.” This is sound advice—it does make the application more robust. When followed naïvely, it also makes the application much slower. If you simply replace a remote method call (to a server) with two remote method calls (one to the naming service and then one to the server), you deserve whatever criticism comes your way.
A much better solution is to implement a centralized cache for stubs for remote servers. This cache should meet the following requirements:
It takes logical arguments, such as server names, and returns a stub. As much as possible, the rest of the code should not know about the structure of the application or the location of individual servers. Code is much more robust, and much easier to read, when knowledge about the application topology is encapsulated.
If the cache doesn’t have a stub already, it fetches the stub (and does so in a way that’s transparent to the rest of the application).
The cache expires stubs that haven’t been used in a while. Otherwise, the cache will keep remote server stubs until the client application shuts down. Because having a live stub counts as a reference to the distributed garbage collector, holding on to stubs for long periods of time effectively prevents the server JVM from cleaning up unused resources.
It has a way for you to flush bad stubs (e.g., stubs to servers that no longer exist). When you discover that a stub is bad (e.g., ...