Oracle Application Server Containers for J2EE Enterprise JavaBeans Developer's Guide 10g (9.0.4) Part Number B10324-01 |
|
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.
The following characteristics apply to EJB clustering:
Clustering for each of the session bean types are discussed in the following sections:
For an overview of how clustering works, see the clustering chapter of the Oracle Application Server Containers for J2EE User's Guide.
Note:
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:
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:
Within the OC4J Instance page in the Oracle Enterprise Manager, do the following:
You can test a network for multicast ability by pinging the following hosts:
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 Oracle 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.
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" .../>
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" .../>
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:
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:
The IP address identifies the OC4J running; the port number is an RMI port number.
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.
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.
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
|
Copyright © 2002, 2003 Oracle Corporation. All Rights Reserved. |
|