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.
Figure 15-3. Contexts, request forwarding, and locking
Let’s now restate this in a slightly more detailed way. The context must:
Analyze the request to determine whether it should be handled locally or should be forwarded.
Find the local server or the appropriate subcontext.
Either return the server or forward the message.
Let’s look at the ...