EJB server selection policy
An EJB server selection policy defines how clients (such as servlets, stand-alone Java clients, or other EJBs) choose among EJB cluster members (instances). EJB workload management offers the following selection policies:
Server weighted round robin routing The server weighted round robin routing will select the next currently available cluster member. The policy ensures a distribution based on the set of server weights that have been assigned to the members of a cluster. For example, if all servers in the cluster have the same weight, the expected distribution for the cluster would be that all servers receive the same number of requests. If the weights for the servers are not equal, the distribution mechanism will send more requests to the higher weight value servers than the lower weight value servers. The policy ensures the desired distribution, based on the weights assigned to the cluster members.
The server weight value defaults to 2 for each member of the cluster and is maintained in the cluster routing table.
Tip: When setting the server weight values for your cluster members, utilize low values to avoid load variations.
For example, you would be better off by setting server weights to 2 and 5 versus 8 and 20 so the refresh will occur more often and thus the server with the weight of 8 won't have to sit idle while 12 requests go to the server with a weight of 20. It would only sit idle for three requests instead of 12 requests.
Valid values for the weights range from 0 to 20.
If a particular EJB server instance is stopped or otherwise unavailable, that instance is skipped (no attempt is made to select it) until it can be verified as being back in service.
The ORB in the EJB client has a routing table for each cluster. The routing table is re-calculated for every new request that comes in. There are no additional requests to an appserver once its outstanding request ratio has reached its server weight value, but there are exceptions to this rule:
Transaction affinity Within a transaction, the first time an EJB server (entity bean) is chosen, the prevailing selection policy for the cluster member is applied. After the EJB server is selected, it remains bound for the duration of the transaction.
Process affinity When the Web container and the EJB container are configured in the same appserver, the Web container never routes EJB requests to a container in a separate application server.
Note Process affinity applies to servlet and EJB clients only. It does not affect stand-alone Java clients, because their EJB requests come from outside of the appserver process.
Prefer local (selected by default) Along with the server weighted round robin routing, there is also a Prefer local policy.
Once the Prefer local policy is turned on, it is used for every cluster member in your cluster. Similarly, when you turn it off, it is off for every cluster member in your cluster.
With the Prefer local policy, the selection made by the WLM plug-in not only depends on the running cluster members, but also on the node (= machine) where the request comes from. The WLM plug-in only selects cluster members on the same node as the client, unless all local cluster members are unavailable.
The advantage of the Prefer local policy is that there are no network communications between the client and the EJB, so depending on the chosen topology, this policy can provide improved performance.
The client is the Java virtual machine (JVM) in which the code calling the EJB is running. This client might be a WebSphere process such as an appserver running a Web container, or an application server running an EJB container.
When a servlet calls an EJB, the client is the appserver that contains the servlet, and if the Prefer local policy is selected, the requests will go to the EJB container running on the same system. If EJB1 is calling EJB2, the client is the application that is running the EJB container containing EJB1. With the Prefer local policy, the requests will go to the same EJB container if EJB2 can be found (see 6.6.3, Process affinity), or to another EJB container running on the same system.
This client might also be a Java virtual machine not running in WebSphere, such as a J2EE client application, or a stand-alone Java program accessing EJBs. For a J2EE client application, the Prefer local policy has no influence on the request distribution because the client runs on a remote workstation.
In the case of a Java program running on the same machine as WebSphere and using the WebSphere JRE and its ORB, the Prefer local policies will dispatch requests among EJB containers running on the same machine. EJB WLM requires the WebSphere ORB and its WLM plug-in. If non-WebSphere ORBs are used, then the Java client will not be able to participate in EJB WLM.
If there is no cluster member available on the local system (because of a failure, or because of the topology), the request will be dispatched to available cluster members following the server weighted round robin routing policy, as described in 6.6.1, WLM behaviors using server weighted round robin.
Note Server weighted round robin routing replaces the random and round robin routing for EJB WLM that was used in WAS V4.0, Advanced Edition.
The Prefer local option is based on topology and pre-production test results. Naturally, the local host call will be quicker, and if you can put your clients (usually Web containers) on the same machines as your servers, the Prefer local option is a good choice. If you have clients only on a subset of your machines, then you will need to analyze the load distribution, since you will have client requests coming from remote machines as well as from the local machine.
Next we show how to configure server weighted round robin routing and Prefer local.
Prev | Home | Next WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.