| Oracle® Containers for J2EE Enterprise JavaBeans Developer's Guide 10g Release 3 (10.1.3) B14428-02 |
|
 Previous |
 Next |
| Oracle® Containers for J2EE Enterprise JavaBeans Developer's Guide 10g Release 3 (10.1.3) B14428-02 |
|
Previous |
Next |
This chapter describes the OC4J application clustering options you can configure for your EJB application, including:
For more information, see "Understanding OC4J EJB Application Clustering Services"
The general procedure for configuring EJB application clustering for an EJB 3.0 or EJB 2.1 stateful session bean is:
Configure your OC4J application cluster (see "Application Clustering in OC4J" in the Oracle Containers for J2EE Configuration and Administration Guide).
Configure a replication policy for stateful session beans on each node (see "Using Deployment XML"):
Deploy your EJB to any one of the nodes in the cluster.
For more information, see "State Replication".
To configure a replication policy, add a <replication-policy> element to one or more of the appropriate deployment descriptor files that Table 24-1 lists.
You can specify a single replication policy that OC4J applies globally or specify finer-grained replication policy at the application level for both Web and EJB components or EJB components only.
Configure the trigger attribute to one of the following:
onRequestEnd — replicate at the end of each EJB method call
onShutdown — replicate when the JVM is terminating normally
The scope attribute is always set to allAttributes for a stateful session bean.
For more information, see "State Replication Trigger".
Table 24-1 Deployment XML Files for Replication Policy Configuration
| Scope | Affected Components | Deployment XML File | See also ... |
|---|---|---|---|
|
Global |
Web and EJB |
|
"Configuring Global Replication Policy in the application.xml File for Web and EJB Components" |
|
Application-level |
Web and EJB |
|
|
|
Application-level |
EJB |
|
"Overriding Application-Level Replication Policy in the orion-ejb-jar.xml File for EJB Components" |
When you configure the application.xml file with a state replication policy (see Example 24-1), it applies to all Web components and to all stateless session beans deployed to this instance of OC4J.
When you configure the orion-application.xml file with a state replication policy (see Example 24-2), it applies to all Web components and to all stateless session beans deployed to this instance of OC4J.
When you configure the orion-ejb-jar.xml file with a state replication policy for a stateful session bean (see Example 24-3), each bean can use a different type of replication independent of the Web component replication type.
Example 24-3 The orion-ejb-jar.xml For an Application-Level Replication Policy for EJBs
<orion-ejb-jar>
...
<session-deployment
name="AirlinePOEndpointBean"
max-tx-retries="0"
location="AirlinePOEndpointBean"
persistence-filename="AirlinePOEndpointBean">
...
<replication-policy
trigger="onRequestEnd" scope="allAttributes"
/>
...
</session-deployment>
...
</orion-ejb-jar>
For both EJB 3.0 and EJB 2.1, to configure how a client's requests are load balanced across the OC4J instances in your cluster when you configure a replication policy (see "Using System Properties").
For more information, see "Replication-Based Load Balancing".
In this release, configure the oracle.j2ee.rmi.loadBalance system property within each client to specify load balancing in an application cluster. This system property takes one of the following values:
client — The client interacts with the OC4J process that was initially chosen at the first lookup for the entire conversation (Default).
context — The client goes to a new server when a separate context is used (similar to deprecated dedicated.rmicontext).
lookup — The client goes to a new (randomly selected) server for every request.
To use static retrieval of OC4J instances for load balancing, within each client, configure JNDI properties as follows (see "Using JNDI Properties":
For java.naming.factory.initial, use any initial context factory.
For the java.naming.provider.url, use the ormi:// prefix and a comma separated list of OC4J nodes in the form <hostname>:<port>/<application-name>
For more information, see "Static Retrieval Load Balancing".
Example 24-4 shows a URL definition that provides the client container with three OC4J nodes (with hostnames s1, s2, and s3 and ports 23791, 23792, and 23793, respectively) to use for load balancing.
Example 24-4 JNDI Properties for Static Retrieval Load Balancing
java.naming.factory.initial= oracle.j2ee.rmi.RMIInitialContextFactory java.naming.provider.url=ormi://s1:23791/ejbs, ormi://s2:23792/ejbs, ormi://s3:23793/ejbs; java.naming.security.principal=admin java.naming.security.credentials=welcome
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, configure JNDI properties as follows (see "Using JNDI Properties"):
For java.naming.factory.initial, use any initial context factory.
For the java.naming.provider.url, use the ormi:// prefix, the single host name to which the OC4J IP addresses are mapped, and the common RMI port.
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.
For more information, see "DNS Load Balancing".
In Example 24-5, the initial context factory is RMIInitialContextFactory (however, you can use any initial context factory for DNS load balancing), myserver is the host name set up in the DNS server for the list of servers, and the RMI port is the default port.
