|
Oracle® Application Server Containers for J2EE Enterprise JavaBeans Developer's Guide
10g Release 2 (10.1.2) Part No. B15505-02 |
|
 Previous |
 Next |
|
Oracle® Application Server Containers for J2EE Enterprise JavaBeans Developer's Guide
10g Release 2 (10.1.2) Part No. B15505-02 |
|
|
Previous |
Next |
The methods for providing clustering —including load balancing and failover—are different for HTTP requests than for EJB communications because Web components use different protocols than EJB components. This chapter specifically discusses EJB clustering. For a complete overview of Oracle Application Server clustering—including the instructions for setting up the HTTP failover and load balancing environment—see the clustering chapter in the Oracle Application Server Containers for J2EE User's Guide.
The following is discussed in this chapter:
Clustered EJBs behave in their own manner. However, only stateful session beans are clustered. To create an EJB cluster, you specify nodes that are to be involved in the cluster, configure each OC4J instance within the node with the same multicast address, username, and password, and deploy the EJB to one of these nodes.
|
Caution: EJB clustering only works over the ORMI protocol, not over the RMI/IIOP protocol. |
The following characteristics apply to EJB clustering:
Unlike HTTP clustering, EJBs involved in a cluster cannot be sub-grouped in an island. Instead, all EJBs within the cluster are in one group.
Transactions cannot failover. There is no reinstating an interrupted transaction in another bean. Instead, the transaction rolls back and must start over.
Load balancing occurs in a random fashion throughout all OC4J processes in the cluster for EJBs.
The performance for clustering stateful session beans is dependent on the type of replication and load balancing options you choose.
Clustering for each of the session bean types are discussed in the following sections:
Combination of HTTP and EJB Clustering
|
Note: For an overview of how clustering works, see the clustering chapter of the Oracle Application Server Containers for J2EE User's Guide. |
Stateless session beans do not have any state to be replicated among hosts in a cluster. Thus, no failover option is necessary. Load balancing is provided automatically with OPMN, which uses a random algorithm. Stateless session beans are not clustered; the load balancing happens in any environment where the OPMN components know about each other. You can configure the frequency of the load balancing from the client using the options described in "Load Balancing Options".
Load balancing is provided automatically with OPMN, which uses a random algorithm. Failover requires that the state of the bean is replicated, so that when the original bean terminates unexpectedly, the request can be forwarded to another OC4J process. You can configure the frequency of the load balancing from the client using the options described in "Load Balancing Options".
For failover, stateful session beans must replicate state among hosts. There are three options for stateful session bean replication, where each option defines the interval when the bean state is sent. All of the state is sent out to all other OC4J processes in the cluster, so it can have an impact on your performance. The fewer times the state is sent out, the better your performance. However, there is a trade-off between performance and the confidence that the bean state is replicated to cover for all areas of the bean instance failing. Thus, choose one of the following replication modes:
JVM termination replication—The state of the stateful session bean is replicated to only one other host in the cluster (with the same multicast address, port) when the JVM is terminating. Since this uses JDK 1.3 shutdown hooks, you must use JVM version 1.3 or later. 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 is not replicated if the host is terminated unexpectedly.
The state of the bean exists only on a single host at any time; you carry a higher risk that the state does not replicate and is lost.
End of call replication—The state of the stateful session bean is replicated to all hosts in the cluster (with the same multicast address, port) at the end of each EJB method call. If the node loses power, then the state has already been replicated. This method is less performant than the JVM termination replication mode, because the state is sent out more often. However, the guarantee for reliance is higher.
See "Configure EJB Replication for Stateful Session Beans" for configuration and implementation details for each of these stateful session bean clustering options.
If you have a servlet that invokes an EJB, you must configure both HTTP and EJB clustering. For HTTP clustering options, see the Clustering chapter of the Oracle Application Server Containers for J2EE User's Guide.
For a full description of how to set up an OC4J cluster, see the Oracle Application Server Containers for J2EE User's Guide.This section describes how to only configure for EJB state replication within the cluster.
To enable the OC4J nodes for EJB clustering, you must perform the following tasks:
Configure each host in the cluster with an identical multicast address (host and port number), including a username and password.
If you have stateful session beans, choose state replication type.
Deploy the EJB to be clustered.
Within the OC4J Instance page in the Enterprise Manager, do the following:
Select the Administration page.
Select Replication Properties in the Instance Properties column.
Scroll down to the EJB Applications section. Figure 12-1 shows this section.
Select the Replicate State checkbox.
Optionally, you can provide the multicast host IP address and port number. If you do not provide the host and port for the multicast address, it defaults to host IP address 230.230.0.1 and port number 9127. The host IP address must be between 224.0.0.2 through 239.255.255.255. Do not use the same multicast address for both HTTP and EJB multicast addresses.
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.
Provide the username and password, which is used to authenticate itself to other hosts in the cluster over the multicast address. The username and password must be consistent in the multicast address to be in the same cluster.
Provide the host name where the OC4J Instance resides in the RMI Server Host field.
Configure the type of stateful session bean replication within the orion-ejb-jar.xml file within the JAR file. See "Configure EJB Replication for Stateful Session Beans" for full details. You can configure these within the orion-ejb-jar.xml file before deployment or add this through the Enterprise Manager screens after deployment. If you add this after deployment, drill down to the JAR file from the application page.
Modify the orion-ejb-jar.xml file to add the state replication configuration for stateful session beans. Since you configure the replication type for the stateful session bean within the bean deployment descriptor, each bean can use a different type of replication.
When EJB clustering is enabled, JNDI namespace replication is also enabled between the OC4J instances in a cluster. New bindings to the JNDI namespace in one OC4J instance are propagated to other OC4J instances in the cluster. Re-bindings and unbindings are not replicated. The replication is completed outside the scope of OC4J islands. In other words, multiple islands in an OC4J instance have visibility into the same replicated JNDI namespace. For more information see the Oracle Application Server Containers for J2EE Services Guide.
Load balancing for EJBs occurs across all OC4J processes included in the cluster.
The client retrieves a random OC4J process when the first lookup is executed. The selection of which OC4J process that services the client is always randomly chosen from among the pooled OC4J processes in the cluster. However, you can choose to have the client do the following:
If you do not set any options, then the client interacts with the OC4J process that was initially chosen at the first lookup for the entire conversation.
If you do set one of two options, then the client chooses another OC4J process with which to interact at specific points in the client's implementation. Each time a client requests another OC4J process, this process is also chosen randomly from the OC4J processes involved in the cluster.
These options are as follows:
LoadBalanceOnLookup property: If this property is set to true, then the client randomly picks another OC4J process from the pooled processes in the cluster each time a lookup is executed. You should only use RMIInitialContextFactory object with this option.
The following configures the LoadBalanceOnLookup property on the client to true in the JNDI properties before retrieving the InitialContext:
env.put("LoadBalanceOnLookup", "true");
dedicated.rmicontext property: If this property is set to true, then each time the client retrieves a new InitialContext, the client also retrieves a new OC4J process. If you want to use multiple OC4J processes within your client, this option is more performant and less burdensome on the application server than the LoadBalanceOnLookup property.
If you are not interested in EJB state replication, but want to load balance your request among OC4J processes, the following sections describe your options:
If you decide to not use EJB replication, but you want to load balance the request across several OC4J processes, you can use static retrieval by providing the URLs for all of these processes in the JNDI URL property.
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;
Alternatively, if you do not want to use EJB replications, but you want to load balance the request using DNS for load balancing, you can do the following:
Within DNS, map a single host name to several IP addresses. Each of the port numbers must be the same for each IP address. Set up the DNS server to return the addresses either in a round-robin or random fashion.
The IP address identifies the OC4J running; the port number is an RMI port number.
Turn off DNS caching on the client. For UNIX machines, you must turn off DNS caching as follows:
Kill the NSCD daemon process on the client.
Start the OC4J client with the -Dsun.net.inetaddr.ttl=0 option.
Within each client, use ANY initial context factory to create an initial context. Use the ormi:// prefix in the provider URL. Use the single host name in the DNS server to which the OC4J IP addresses are mapped and the common RMI port in the provider URL for the client.
Set the dedicated.rmicontext property to true.
Each time the lookup occurs on the DNS server, the DNS server hands back one of the many IP addresses that are mapped to it.
Example 12-1 RMIInitialContextFactory Example
This example uses an RMIInitialContextFactory object; however, you can use any initial context factory for DNS load balancing. In this example, myserver is the host name set up in the DNS server for the list of servers, and the RMI port is defaulting to the default port.
java.naming.factory.initial=
com.evermind.server.rmi.RMIInitialContextFactory
java.naming.provider.url=ormi://myserver/applname
java.naming.security.principal=admin
java.naming.security.credentials=welcome
dedicated.rmicontext=true
