3-8 Using Clusters for Oracle WebLogic Server
For best performance, configure enough socket reader threads in the Java Virtual Machine JVM that runs the client. For instructions, see
Section 10.2.18.1.3, Set the Number of Reader Threads on Client Machines.
3.2 Cluster-Wide JNDI Naming Service
Clients of a non-clustered WebLogic Server server instance access objects and services by using a JNDI-compliant naming service. The JNDI naming service contains a list of
the public services that the server instance offers, organized in a tree structure. A WebLogic Server instance offers a new service by binding into the JNDI tree a name
that represents the service. Clients obtain the service by connecting to the server instance and looking up the bound name of the service.
Server instances in a cluster utilize a cluster-wide JNDI tree. A cluster-wide JNDI tree is similar to a single server instance JNDI tree, insofar as the tree contains a list of
available services. In addition to storing the names of local services, however, the cluster-wide JNDI tree stores the services offered by clustered objects EJBs and RMI
classes from other server instances in the cluster.
Each WebLogic Server instance in a cluster creates and maintains a local copy of the logical cluster-wide JNDI tree. The follow sections describe how the cluster-wide JNDI
tree is maintained, and how to avoid naming conflicts that can occur in a clustered environment.
3.2.1 How WebLogic Server Creates the Cluster-Wide JNDI Tree
Each WebLogic Server in a cluster builds and maintains its own local copy of the cluster-wide JNDI tree, which lists the services offered by all members of the cluster.
Creation of a cluster-wide JNDI tree begins with the local JNDI tree bindings of each server instance. As a server instance boots or as new services are dynamically
deployed to a running server instance, the server instance first binds the implementations of those services to the local JNDI tree. The implementation is bound
into the JNDI tree only if no other service of the same name exists.
Once the server instance successfully binds a service into the local JNDI tree, additional steps are performed for clustered objects that use replica-aware stubs. After
binding the clustered objects implementation into the local JNDI tree, the server instance sends the objects stub to other members of the cluster. Other members of the
cluster monitor the multicast or unicast address to detect when remote server instances offer new services.
Caution: Do not use the cluster-wide JNDI tree as a persistence or
caching mechanism for application data. Although WebLogic Server replicates a clustered server instances JNDI entries to other server
instances in the cluster, those entries are removed from the cluster if the original instance fails. Also, storing large objects within the JNDI
tree can overload multicast or unicast traffic and interfere with the normal operation of a cluster.
Note:
When you start a Managed Server in a cluster, the server instance identifies other running server instances in the cluster by
listening for heartbeats, after a warm-up period specified by the MemberWarmupTimeoutSeconds parameter in ClusterMBean. The
default warm-up period is 30 seconds.
Communications In a Cluster 3-9
Figure 3–4 shows a snapshot of the JNDI binding process.
Figure 3–4 Server A Binds an Object in its JNDI Tree, then Unicasts Object Availability
In the previous figure, Server A has successfully bound an implementation of clustered Object X into its local JNDI tree. Because Object X is clustered, it offers this
service to all other members of the cluster. Server C is still in the process of binding an implementation of Object X.
Other server instances in the cluster listening to the multicast or unicast address note that Server A offers a new service for clustered object, X. These server instances update
their local JNDI trees to include the new service.
Updating the local JNDI bindings occurs in one of two ways:
■
If the clustered service is not yet bound in the local JNDI tree, the server instance binds a new replica-aware stub into the local tree that indicates the availability of
Object X on Server A. Servers B and D would update their local JNDI trees in this manner, because the clustered object is not yet deployed on those server instances.
■
If the server instance already has a binding for the cluster-aware service, it updates its local JNDI tree to indicate that a replica of the service is also available on Server
A. Server C would update its JNDI tree in this manner, because it will already have a binding for the clustered Object X.
In this manner, each server instance in the cluster creates its own copy of a cluster-wide JNDI tree. The same process would be used when Server C announces
that Object X has been bound into its local JNDI tree. After all broadcast messages are received, each server instance in the cluster would have identical local JNDI trees that
indicate the availability of the object on Servers A and C, as shown in
Figure 3–5 .
3-10 Using Clusters for Oracle WebLogic Server
Figure 3–5 Each Servers JNDI Tree is the Same after Unicast Messages are Received
3.2.2 How JNDI Naming Conflicts Occur
