7
EJB Clustering

EJB clustering offers improved scalability and high-availability through the following circumstances:

At a certain point, too many incoming client requests can overpower the abilities of your server. You can set up your environment to balance the load of incoming client requests among several servers.
Servers failing and connections dropping occasionally happens. You can configure several servers in a cluster, so that communication is rerouted to another server in a failover situation.

The methods for providing load balancing and clustering for failover are different for HTTP requests than for EJB communications because Web components use different protocols than EJB components. This chapter discusses EJB clustering; the instructions for setting up the HTTP failover and load balancing environment is detailed in Oracle9i Application Server Performance Guide.

The following is discussed in this chapter:

EJB Clustering Overview

To create an EJB cluster, you specify OC4J nodes that are to be involved in the cluster, configure each of them with the same multicast address, username, and password, and deploy the EJB to be clustered to each of the nodes in the cluster.

Unlike HTTP clustering, OC4J nodes included in an EJB cluster are not currently grouped in an island and do not have a load balancer as a front-end. Instead, the EJB client container stubs discover--either statically or dynamically--all the OC4J nodes in the EJB cluster, shuffle the destination addresses, and choose one from this group for the connection. Thus, the only method for load balancing and failover is a random methodology.

As Figure 7-1 demonstrates, the client container stubs chose server "s1" for its EJB connection. However, sometime during the conversation, the connection went down. At this point, the client container stubs shuffle the remaining OC4J node addresses and choose another server to connect to for the failover. In this example, server "s3" from the OC4J cluster resumes the conversation.

Figure 7-1 EJB Clustering Diagram

Text description of clustera.gif follows

Text description of the illustration clustera.gif

The client container stubs discover the OC4J server addresses by one of the following methods:

static cluster discovery method

The JNDI addresses of all OC4J nodes that should be contacted for load balancing and failover are provided in the lookup URL, and each address is separated by a comma. For example, the following URL definition provides the client container with three OC4J nodes to use for load balancing and failover.
```
java.naming.provider.url=ormi://s1:23791/ejbsamples, 

	ormi://s2:23793/ejbsamples, ormi://s3:23791/ejbsamples;
```
dynamic cluster discovery method

The JNDI addresses of all OC4J nodes that can be contacted for load balancing and failover are dynamically discovered during the first JNDI lookup. The client must perform a lookup with a "lookup:" prefix, as follows:
```
ic.lookup("lookup:ormi://s1:23971/ejbsamples");
```
During the JNDI lookup, server "s1" contacts the other OC4J nodes in the cluster, which are identified as a cluster if they all have the same multicast address (host/port), and retrieves their ormi addresses. These addresses are sent back to the client container. From this point forward, the client container shuffles these addresses for any load balancing or failover needs.

However, the client container never tries to rediscover these addresses. Therefore, if you remove a node from the cluster and add another one during the connection, the client container will be unaware of it until the next time the client re-discovers the cluster nodes through the "lookup:" method.

The state of all beans are replicated at the end of every method call to all nodes in the cluster. This option is the most reliable in that the state of the bean is replicated to all nodes in the cluster, using a JMS multicast topic to all nodes in the cluster--which uses the same multicast address. This state stays in the topic until it is needed. Then when a method call comes in on the alternate node, the latest state for the bean is found in the JMS topic, reinstated, and the bean invocation continues.

These methods have different repercussions for each of the EJB types, which are discussed in the following sections:

Stateless Session Bean Clustering

Stateless session beans do not require any state to be replicated among nodes in a cluster. Thus, the only use of the clustering methods that stateless session beans have is load balancing between nodes. Both the dynamic and state cluster discovery methods can be used for stateless session beans. Failover defaults to the remote invocation handler by redirecting a request.

Stateful Session Bean Clustering

Stateful session beans require state to be replicated among nodes. In fact, stateful session beans must send all their state between the nodes, which can have a noticeable effect on performance. Thus, the following replication modes are available to you to decide on how to manage the replication performance cost:

JVM termination replication mode--The state of the stateful session bean is replicated to only one other node in the cluster when the JVM is terminating, which uses JDK 1.3 shutdown hooks. Thus, you must use JVM version 1.3 or later. Within the JVM shutdown process, the state of all stateful session beans within this JVM is replicated to another server on the same multicast address. This is the most performant option, because the state is replicated only once. However, it is not very reliable, for the following reasons:
- Your state will not be replicated if the power is shut off unexpectedly.
- The state of the bean exists only on a single node at any time; the depth of failure is equal to one node.
Stateful session context replication model--This is a finer-grain replication mode. In HTTP clustering, you can manage when and the type of information that is replicated through the setAttribute method of the HTTPSession object. Oracle offers a similar method through a new OC4J-specific class: com.evermind.server.ejb.statefulSessionContext. Although this option is a performant and reliable mechanism, it does not comply with the J2EE specification. Thus, if you provide this within your server code, you cannot port this application to any non-Oracle J2EE server.

Entity Bean Clustering

The state of the entity bean is saved in a persistent storage, such as a database. Thus, when the client loses the connection to one node in the cluster, it can switch to another node in the cluster without worrying about replication of the entity bean state. However, to ensure that the state is updated from the persistent storage when the load balancing occurs, the entity bean that changes state notifies other nodes that their state is no longer in synch. That is, that their state is "dirty". At this point, nothing is done. If failover occurs and the client accesses another node for this entity bean, then the bean notices that its cache is dirty and resynchronizes its cache to the "READ_COMMITTED" state within the database.

Combination of HTTP and EJB Clustering

If you have a servlet that invokes an EJB, you must include both the HTTP and EJB clustering. For HTTP clustering options, see the HTTP clustering white paper. The type of EJB clustering you choose is based on the EJB type. If you do not configure for both types, you will not have the proper state replication for the type for which you did not configure.

If the HTTP invokes an EJB that is colocated, the EJBReference cannot be replicated to another node unless EJB clustering has been enabled. Instead, a null pointer will be copied to the other node. So, you must provide for both types of clustering in order for all of the correct information to be replicated.

Enabling Clustering For EJBs

To enable the OC4J nodes for EJB clustering, you must perform the following steps:

Configure each node in the cluster with the multicast address and a unique node identifier.
Configure state replication for any stateful session beans or state synchronization for entity beans.
Deploy the EJB to be clustered on all nodes.
Modify the client to use either the dynamic or static method for retrieving the cluster node addresses. The dynamic method is recommended.

Configure Nodes With Multicast Address and Identifier

When you are configuring each OC4J node included in the EJB cluster, you must configure each node with an identical multicast address (host and port number), username, and password. However, each node in the cluster should also include its own unique identifier within the cluster. You can test a network for multicast ability by pinging the following hosts:

To ping all multicast hosts, execute: ping 224.0.0.1.
To ping all multicast routers, execute: ping 224.0.0.2.

Modify the rmi.xml file and add the <cluster> tag to configure the multicast address, username, password, and identifier for the OC4J node, as follows:

<cluster host=<multi_host> port=<multi_port>
	username=<multi_user> password=<multi_pwd> />

where each variable should be the following:

multi_host: The multicast host used for the EJB cluster that communicates among the nodes in the cluster. The IP addresses that you can use for multicast are between 224.0.0.0 and 239.255.255.255. You must specify this variable.
multi_port: The multicast port used for the EJB cluster for communication among the nodes in the cluster.
multi_user/multi_pwd- The username and password used to authenticate itself to other nodes in the cluster. If the username and password are different for other nodes in the cluster, they will fail to communicate. You can have multiple username and password combinations within a multicast address. Those with the same username/password combinations will be considered a unique cluster.

For example, the following cluster definition identifies a cluster on mulitcast address of host=230.0.0.1, port=9127, username=mult1, and password=hwdr:

<cluster host="230.0.0.1" port="9127" 

	username="mult1" password="hwdr"/>

You can specify the node identifier number as follows:

Specify the node identifier in the server.xml file with the <cluster> tag, as follows:
```
<cluster id="123"/>
```

If no identifier is specified, a default identifier consists of the host IP address and port of the node itself.

Note:

The dynamic peer discovery mechanism uses RMI as the mechanism for communication. You must have an RMI listener configured in the rmi.xml file with the following syntax:

<rmi_server host="<hostname>" port="<port>" />

The host name must be the actual name of your node. Do not use the "localhost" variable.

EJB Replication Configuration

Modify the orion-ejb-jar.xml file to add the configuration for stateful session beans and entity beans require for state replication. The following sections offer more details:

Stateful Session Bean Replication Configuration

You configure the replication type for the stateful session bean within the bean deployment descriptor. Thus, each bean can use a different type of replication.

VM Termination Replication

Set the replication attribute of the <session-deployment> tag in the orion-ejb-jar.xml file to "VMTermination". This is shown below:

<session-deployment replication="VMTermination" .../>

End of Call Replication

Set the replication attribute of the <session-deployment> tag in the orion-ejb-jar.xml file to "endOfCall". This is shown below:

<session-deployment replication="EndOfCall" .../>

Stateful Session Context

No static configuration is necessary when using the stateful session context to replicate information across the clustered nodes. To replicate the desired state, set the information that you want replicated and execute the setAttribute method within the StatefulSessionContext class in the server code. This enables you to designate what information is replicated and when it is replicated. The state indicated in the parameters of this method is replicated to all nodes in the cluster that share the same multicast address, username, and password.

Entity Bean Replication Configuration

Configure the clustering for the entity bean within its bean deployment descriptor.

Modify the orion-ejb-jar.xml file to add the clustering-schema attribute to the <entity-deployment> tag, as follows:

<entity-deployment ... clustering-schema="asynchronous-cache" .../>

Deploy EJB Application To All Nodes

Deploy the EJB application to all nodes in the cluster. If you do not do so, the client container shuffles through the nodes in the cluster until it finds a node with the EJB deployed on it. This will affect your performance.

You can either deploy the application to each node individually using the -cluster option of the admin.jar tool or you can use Oracle Enterprise Manager (OEM), which can deploy your application for you to multiple nodes.

Use the following syntax with the admin.jar tool:

java -jar admin.jar ormi://myhost admin welcome 

	-deploy -file bmpapp.ear -deploymentName bmpapp -cluster

Application Client Retrieval Of Clustered Nodes

The client container designates randomly within the nodes in the cluster where to direct the client request. As discussed above, the container discovers the nodes within the cluster through one of the following methods:

Static Retrieval

The JNDI addresses of all OC4J nodes that should be contacted for load balancing and failover are supplied in the lookup URL, and each address is separated by a comma. For example, the following URL definition provides the client container with three OC4J nodes to use for load balancing and failover.

java.naming.provider.url=ormi://s1:23791/ejbsamples, 

	ormi://s2:23793/ejbsamples, ormi://s3:23791/ejbsamples;

Dynamic Retrieval

The JNDI addresses of all OC4J nodes that can be contacted for load balancing and failover are dynamically discovered during the first JNDI lookup. The client must perform a lookup with a "lookup:" prefix, as follows:

ic.lookup("lookup:ormi://s1:23971/ejbsamples");

During the JNDI lookup, server "s1" contacts the other OC4J nodes in the cluster, which are identified as a cluster if they all have the same multicast address (host/port), and retrieves their ormi addresses. These addresses are sent back to the client container. From this point forward, the client container shuffles these addresses for any load balancing or failover needs.

The client container never tries to rediscover these addresses, though. Therefore, if you remove a node from the cluster and add another one during the connection, the client container will be unaware of it until the next JNDI lookup.

Load Balancing Options

If you configure for load balancing, it balances the load at the connection level. However, if you want load balancing to occur on each JNDI lookup, configure the LoadBalanceOnLookup property to true in the JNDI properties before retrieving the InitialContext, as follows:

env.put("LoadBalanceOnLookup", "true");

7EJB Clustering