Load balancing and failover for EJBs and RMI objects is handled using replica-aware stubs, which can locate instances of the object throughout the cluster. EJBs differ from plain RMI objects in that each EJB can potentially generate two different replica-aware stubs: one for the EJBHome interface and one for the EJBObject interface. This means that EJBs can potentially realize the benefits of load balancing and failover at two levels:
- When a client looks up an EJB object using the EJBHome stub.
- When a client makes method calls against the EJB using the EJBObject stub.
The following sections describe clustering support for different types of EJBs.
Clustering Stateless EJBs
Since a stateless bean holds no state on behalf of the client, the stub is free to route any call to any server that hosts the bean. In order to declare a Stateless EJB as clusterable, you need to set to true the element stateless-bean-is-clusterable in your weblogic-ejb-jar.xml:
<stateless-clustering>
<stateless-bean-is-clusterable>True</stateless-bean-is-clusterable>
<stateless-bean-load-algorithm>random</stateless-bean-load-algorithm>
</stateless-clustering>
The stub can automatically fail over in the event of a failure. The stub does not automatically treat the bean as idempotent, so it will not recover automatically from all failures. If the bean has been written with idempotent methods (e.g. there is no additional effect if the EJB is called more than once with the same input parameters), this can be noted in the deployment descriptor as follows, and automatic failover will be enabled in all cases.
<stateless-clustering>
. . . . .
<stateless-bean-methods-are-idempotent>true</stateless-bean-methods-are-idempotent>
</stateless-clustering>
Clustering Stateful EJBs
Method-level failover for a stateful service requires state replication. WebLogic Server satisfies this requirement by replicating the state of the primary bean instance to a secondary server instance, using a replication scheme similar to that used for HTTP session state.
As you can see from the following weblogic-ejb-jar.xmlsnippet, you can configure the replication schema by setting the replication-type element, much the same way we did for the HTTP counterpart:
<stateful-session-descriptor>
<stateful-session-clustering>
<home-is-clusterable>true</home-is-clusterable>
<home-load-algorithm>random</home-load-algorithm>
….
<!– None for not to replicate –>
<replication-type>InMemory</replication-type>
</stateful-session-clustering>
</stateful-session-descriptor>
Should the primary server fail, the client’s EJB stub automatically redirects further requests to the secondary WebLogic Server instance. At this point, the secondary server creates a new EJB instance using the replicated state data and processing continues on the secondary server. After a failover, WebLogic Server chooses a new secondary server to replicate EJB session states
Configuring the default load balancing algorithm
WebLogic Server clusters support multiple algorithms for load balancing clustered EJBs and RMI objects: round-robin, weight-based, random, round-robin-affinity, weight-based-affinity, and random-affinity.
By default, a WebLogic Server cluster will use the round-robin method. You can configure a cluster to use one of the other methods using the Administration Console as follows:
- Select Environment | Clusters within the Domain Structure panel of the console.
- Select a specific cluster. On the General tab, update any of the fields contained as described by the following picture:
You can specify the cluster address using a comma-separated list of hostnames and port numbers.
Remember that any address/port combination in the cluster address must be unique. This means that if you need to run a WebLogic cluster on a single machine, you must ensure all server instances participating in the cluster are assigned a unique port number.
As mentioned in WebLogic documentation, when clients obtain an initial JNDI context by supplying the cluster DNS name (weblogic.jndi.WLInitialContextFactory), it obtains the list of all addresses that are mapped to the DNS name. This list is cached by WebLogic Server instances and new Initial Context requests are fulfilled using addresses in the cached list with a round-robin algorithm. If a server instance in the cached list is unavailable, it is removed from the list. The address list is refreshed from the DNS service only if the server instance is unable to reach any address in its cache.
Using a cached list of addresses avoids certain problems with relying on DNS round-robin alone. For example, DNS round-robin continues using all addresses that have been mapped to the domain name, regardless of whether or not the addresses are reachable. By caching the address list, WebLogic Server can remove addresses that are unreachable so that connection failures aren’t repeated with new Initial Context requests.
