JNDI and Clustering
From the client's perspective, a WebLogic cluster should appear as one high-performance and fault-tolerant server. This idea carries over to the WebLogic cluster's shared JNDI naming service. The naming service is fault-tolerant because the naming service survives server failures in the cluster. As new servers join the cluster, they automatically participate in the naming service. The naming service is high-performance because each server runs the naming service in parallel, and client requests can be processed on many servers simultaneously.
Replicated Naming Service
Each WebLogic Server maintains its own copy of the cluster's naming service. The advantage of this approach is performance. Each naming service is able to locally cache the cluster's naming tree and handle any naming request out of its own memory. This approach also provides transparency. To a client, a naming service is identical regardless of which clustered server is contacted. However, any distributed caching mechanism brings with it the issue of cache coherency. Whenever a change occurs in the JNDI tree, the other servers must be notified. For instance, when a new object is bound into the JNDI tree at a given name, every naming service must be made aware of the new mapping (see Figure 6-2).
Figure 6-2. Cluster with Replicated Naming Service Propagating Changes
WebLogic maintains the cluster-wide service through network updates. Each clustered WebLogic server sends its JNDI updates over multicast to the other cluster members. IP multicast enables a single message to be delivered to a number of receivers, in this case all the servers in the cluster. For tightly coupled clusters, this is much more efficient because updating n other servers requires a single network message rather than the n messages required by point-to-point connections.
JNDI changes are sent to other cluster members with IP multicast.
When a clustered server receives a JNDI change from another server, it updates its local cached copy of the JNDI tree. It is possible for the update to conflict with another object in the cached copy of the JNDI tree. We discuss how this is possible, and suggest solutions, in a later section.
WebLogic Server's clustered naming service is designed for high performance and to minimize network traffic between servers. Because each server is caching the clustered naming tree, it is possible for the cache to be slightly out of date. In this case, an update has occurred on one server but has not yet reached another server's cache. In general, this is not an issue. Because JNDI is a naming service, it is used to advertise services and objects residing on particular servers. JNDI updates are only sent when a JNDI bind, rebind, or unbind occurs within the cluster. These changes in the JNDI tree are relatively rare, and network traffic and coherency are not very frequently an issue with the WebLogic Server's JNDI implementation.
Understanding Conflicts in the JNDI tree
RMI objects can be compiled as clustered RMI objects or nonclustered objects. There is no change in the RMI code. It merely determines the behavior of the RMI stub used by the RMI subsystem. A clustered RMI object must not store any client-associated state. Many of the WebLogic subsystems (including stateless session EJBs) default to clustered RMI objects.
When an object is bound into the JNDI tree on a WebLogic Server, the WebLogic JNDI service enables the user to specify whether this binding should be replicated to the other clustered servers. By default, bindings are replicated, and the WebLogic Server will send a multicast message to the cluster members. It is also possible to specify that a binding should not be replicated. We will see why this might be desirable in a moment. Nonreplicated bindings must be selected before the InitialContext is created.
Environment env = new Environment(); env.setReplicateBindings(false); Context ctx = env.getInitialContext();
Clustered JNDI with Replicated Bindings
By default, the WebLogic JNDI service replicates bindings to the other servers within the cluster. The semantics of replicated bindings depends on whether the RMI object is clustered or nonclustered.
Clustered RMI objects are aggregated in the JNDI tree. When a clustered object is bound into the JNDI tree, its server is added to the list of servers offering that service. As long as every server binds in the same type, every server can offer a clustered object under a given name. This enables the WebLogic cluster to map a single JNDI name to a service offered by multiple cluster members.
Clustered objects are aggregated in the JNDI tree.
Unlike clustered RMI objects, nonclustered RMI objects do not aggregate in the JNDI tree. When replicated bindings are used, a nonclustered object may not be bound to the same name on multiple servers. This condition is known as a conflict, and will be detected by the WebLogic Servers and an error will be printed to the system log. JNDI conflicts indicate that the WebLogic Servers have been misconfigured.
With replicated bindings, only a single server may bind a nonclustered object to a given name. JNDI conflicts are configuration errors and must be resolved manually by the WebLogic Server administrator.
Clustered JNDI with Nonreplicated Bindings
When the JNDI context is created without replicated bindings, the WebLogic Server will not send a multicast update when the JNDI bind occurs. Nonreplicated bindings can be useful to avoid JNDI conflicts. For instance, an application might read configuration details into a Properties object and bind the Properties object into the JNDI tree. Because this is not a clustered RMI object, there would be a JNDI conflict if multiple servers attempted to bind their Properties to the same name. With nonreplicated bindings, each server binds its own copy of the Properties object. Since there are no multicast updates, there will be no conflict in the JNDI service.
With nonreplicated bindings, each server may bind its own copy of a nonclustered service without receiving a JNDI conflict.