|
Oracle® Containers for J2EE Enterprise JavaBeans Developer's Guide
10g Release 3 (10.1.3) B14428-01 |
|
 Previous |
 Next |
|
Oracle® Containers for J2EE Enterprise JavaBeans Developer's Guide
10g Release 3 (10.1.3) B14428-01 |
|
|
Previous |
Next |
Oracle Application Server provides an extensive suite of high availability and failover options, including clustering: the distribution of application server and end-user application components across multiple hosts configured with the appropriate means of host-to-host communication.
OC4J application clustering is a state management service available to HTTP sessions and stateful session beans. In this context, a cluster is defined as two or more OC4J server nodes hosting the same set of applications. In this release, configuration has been simplified and made identical for both HTTP sessions and stateful session beans.
This section describes OC4J application clustering for stateful session beans, including:
For more information, see:
"Clustering Overview" in the Oracle Containers for J2EE Configuration and Administration Guide
"Application Clustering in OC4J" in the Oracle Containers for J2EE Configuration and Administration Guide
"Oracle Application Server Cluster (OC4J) in Active-Active Topologies" in the Oracle Application Server High Availability Guide
"Stateful Session EJB State Replication with Oracle Application Server Cluster (OC4J)" in the Oracle Application Server High Availability Guide
When you configure a replication policy for a clustered OC4J EJB application, OC4J handles the replication of objects and values contained in stateful session bean instances. Only stateful session beans can be clustered. Because stateless session beans have no state to be replicated, they need not be clustered.
You must configure a replication policy to take advantage of failover (see "Failover"). If you only want to take advantage of load balancing, replication is not required (see "Load Balancing").
A replication policy determines the conditions (see "State Replication Trigger") under which bean state (see "State Replication Scope") is broadcast (see "State Replication Mode") to all other OC4J processes in the cluster.
Replication can have an impact on application server and network 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.
You can configure a replication policy globally for all applications deployed to an OC4J instance or at the application level. You can configure a replication policy for all Web and EJB components and you can configure a replication policy for EJB components only.
For more information on configuring a replication policy for a stateful session bean, see "Configuring EJB 3.0 and EJB 2.1 Stateful Session Bean Replication Policy".
You can choose the condition that triggers replication as one of the following:
inherited — The stateful session bean uses the state replication trigger setting you configure at the application level. This is the default value.
on request end — 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.
on shutdown — 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. 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.
For stateful session beans, when replication is triggered, all the attributes of the stateful session bean are replicated (regardless of whether or not they have changed).
You can configure OC4J EJB application clustering in-memory replication by way of: multicast communication, peer-to-peer communication, or persistence of state data to a database. For more information on configuring replication type, see "Application Clustering in OC4J" in the Oracle Containers for J2EE Configuration and Administration Guide.
Load balancing refers to how incoming client requests are distributed over all the OC4J instances in your cluster.
You can choose from among the following load balancing strategies:
When you configure a replication policy for a clustered OC4J EJB application (see "State Replication"), OC4J can automatically select an OC4J instance at random from the pool of OC4J instances in the cluster when the first client request is serviced. You can configure how subsequent requests will be load balanced.
For more information, see "Configuring Replication-Based Load Balancing".
If you decide not to use EJB replication, but you want to load balance client requests across several statically specified OC4J processes, you can use static retrieval by providing the URLs for all of these processes in the JNDI URL property.
For more information, see "Configuring Static Retrieval Load Balancing".
If you decide not to use EJB replication, but you want to load balance client requests across several DNS-managed OC4J processes, you can use DNS retrieval by configuring your DNS server with a single hostname associated with the desired OC4J host IP addresses and specifying this hostname in the JNDI URL property.
For more information, see "Configuring DNS Load Balancing".
Failover requires that the state of the bean is replicated, so that when the original bean terminates unexpectedly, the request can be transparently forwarded to another OC4J process in the cluster.
For more information, see "State Replication".
Transactions cannot failover. There is no reinstating an interrupted transaction in another bean. Instead, the transaction rolls back and must start over.
For more information, see "Understanding EJB Transaction Services".
The performance for clustering stateful session beans is dependent on the type of replication (see "State Replication") and load balancing (see "Load Balancing") options you choose.
You must choose the appropriate balance between replication frequency and robustness: the more frequently you replicate, the smaller the window of opportunity for losing state but the higher the load on the application server and network.
