O'Reilly logo

Java RMI by William Grosso

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Federation and Threading

One of the most interesting characteristics of hierarchies is that contexts both simplify the design task and make the naming service much more flexible. To see why, we need to make two fairly plausible usage assumptions:

  • Contexts will be small (usually containing fewer than 100 local entries and 10 subcontexts).

  • Most servers for a given application are equally desirable. That is, if an application has multiple servers, they probably all handle similar numbers of requests.

The truth is that neither of these assumptions really holds in practice. However, they almost hold, in the same way that a red-black tree is almost a black tree. And they immediately lead to the following conclusion: contexts are the perfect first pass at thread locks.

For example, suppose a a request comes into a context. The context looks at the request and does one of two things: it either finds a server that has been bound into the context and that satisfies the request, or it forwards the request to the appropriate subcontext. See Figure 15-3.

Contexts, request forwarding, and locking

Figure 15-3. Contexts, request forwarding, and locking

Let’s now restate this in a slightly more detailed way. The context must:

  1. Analyze the request to determine whether it should be handled locally or should be forwarded.

  2. Find the local server or the appropriate subcontext.

  3. Either return the server or forward the message.

Let’s look at the ...

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required