This chapter includes the following topics:
High availability for the Fusion web application is the ability of the application to be available when it is needed.
A high availability environment ensures that users can access the application without loss of service. Deploying the Fusion web application to a high availability environment minimizes the time when the application is down, or unavailable, and maximizes the time when it is running, or available.
High availability comes from redundant systems and components. You can categorize high availability solutions by their level of redundancy into active-active solutions and active-passive solutions.
An active-active solution deploys two or more active servers and can be used to improve scalability and provide high availability. In active-active deployments, all instances handle requests concurrently. Oracle recommends active-active solutions for all single-site middleware deployments. Active-passive solutions deploy an active instance that handles requests and a passive instance that is on standby.
For more information about high availability environments, see the High Availability Guide.
At runtime, ADF objects such as the binding container and managed beans are instantiated. Each of these objects has a defined life span set by its scope attribute.
For more information about the life span of ADF objects, see About Object Scope Lifecycles.
An Oracle WebLogic cluster provides application high availability. If one member of the cluster is unavailable, any other available member of the cluster is able to handle the request. You should familiarize yourself with failover requirements and the expected behavior of an application in the event of a failover.
For seamless failover of a Fusion web application, the application must meet the following conditions:
The application is in a cluster and at least one member of the application cluster is available to serve the request.
For stateful applications, state replication is configured correctly, as described in Configuring Oracle ADF for High Availability.
If you use Oracle HTTP Server, the server is configured with the WebLogicCluster directive to balance among all available application instances.
If you use a hardware load balancer, the load balancer is:
Routing traffic to all available instances
Configured correctly with a health monitor to mark unavailable instances
Configured to support persistence of session state
If the environment is configured correctly, application users do not notice when an application instance in a cluster becomes unavailable. The sequence of events in an application failover is, for example, as follows:
A user makes a request and is routed by a hardware load balancer to Instance A of the application.
Instance A of the application becomes unavailable because of node failure, process failure, or network failure.
The hardware load balancer marks Instance A as unavailable.
The user makes a subsequent request. The request is routed to Instance B.
Instance B is configured as a replication partner of Instance A and has the user's session state.
The application resumes using the session state on Instance B and the user continues working without interruption.
When you configure the ADF application module to access a highly available database system, such as redundant databases or Oracle Real Application Clusters (Oracle RAC) as the backend, the data source must be container-defined. In this scenario, you must use a GridLink data source or a multi data source. However, from the standpoint of the application module configuration, the naming convention for the multi data source or GridLink data source is the same as it is for a non-multi data source or GridLink data source. This naming convention ensures that the correct data source is used at runtime.
To more information about configuring GridLink data sources or multi data sources for high availability applications, see the "Database Considerations" chapter of the High Availability Guide.
For information about high availability considerations related to modifying the mdsDS data source URL post deployment of the Fusion web application, see the "Configuring High Availability for Other Components" chapter of the High Availability Guide.
To support automatic replication and failover for web applications in a clustered environment, Oracle WebLogic Server supports mechanisms for replicating HTTP session state across clusters. You can configure Oracle ADF to ensure the Fusion web application's state can be restored from any server in the cluster.
An application module is the transactional component that the Fusion web application uses to work with application data. It defines an updateable data model and top-level procedures and functions, called service methods, related to a logical unit of work related to an end-user task. An application module supports passivating, or storing, its transaction state as a snapshot in the database. It also supports the reverse operation of activating the transaction state from one of these saved snapshots.
For more information on application module state management, see About Fusion Web Application State Management.
To enable support for ADF Business Components failover, set the jbo.dofailover parameter to true so that the application module state is saved on release. This enables Oracle ADF to restore the application module state from a snapshot saved from a previous check in. By contrast, when the failover feature is disabled, which it is by default, then application module state is saved only when the application is reused by a subsequent user session and only when the application module pool cannot find an unused application module.
You can set this parameter in your application module configuration on the Pooling and Scalability tab of the overview editor for application module configurations (on the bc4j.xcfg file).
To configure application modules for high availability:
bc4j.xcfg file), click the Database and Scalability tab.To enable support for replicating HTTP session state, you must assign a value to the persistent-store-type element in the Oracle WebLogic Server weblogic.xml file. The value replicated_if_clustered ensures that the in-effect persistent store type will be replicated so that sessions on the clustered environment are stored in accordance with the value set for the cluster of servers to which this server belongs.
Note:
Oracle ADF applications such as the Oracle WebCenter Portal Suite are preconfigured and do not need additional configuration.
To configure the weblogic.xml file for high availability:
When you design an application to run in a clustered environment, you must ensure that Oracle ADF is aware of changes to managed beans stored in ADF scopes (view scope and page flow scope).
When a value within a managed bean in either view scope or page flow scope is modified, the application must notify Oracle ADF so that it can ensure the bean's new value is replicated.
To enable ADF Controller to track changes to ADF memory scopes and replicate the page flow scope and view scope within the server cluster, you must set the ADF Controller parameter <adf-scope-ha-support> in the application's adf-config.xml file to true. For example, when set to true for an application and that application adds or removes a bean from a page flow scope during a request, the change will automatically replicated within a cluster.
The adf-config.xml file is the central configuration file for all ADF components. The file contains sections to configure the runtime behavior for ADF components, including, ADF Controller.
Note:
If your application uses MDS and will use an Oracle database that supports failover, Oracle recommends enabling MDS retry on failover. To do this, add the following retry-connection entry to the MDS configuration section of adf-config.xml.
<persistence-config>
<metadata-namespaces>...
<metadata-store-usages>...
<external-change-detection enabled="false" />
<read-only-mode enabled="true"/>
<retry-connection enabled="true"/>
</persistence-config>
To configure the adf-config.xml file for high availability:
For more information about using the adf-config.xml file to configure ADF, see adfc-config.xml.
JSF Application Scope beans are backed by a servlet context which can only have one instance per cluster node. Therefore, for each design time configured bean, there will be a runtime instance of the bean for each node in a cluster. Because there is no synchronization across nodes, each instance of the application running on different nodes will have separate instances of that bean with separate values. Therefore, application scoped managed beans should not be used to carry application-wide values that can be updated to be shared across all nodes in a cluster. They can, however, be used to carry constants, read-only values, or values to reflect the state of a single node within the cluster (such as the number of users on a node).
The org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION context parameter provides optimization for developing and testing the Fusion web application in the JDeveloper. Leaving this parameter set to true when the application runs in a high availability environment can lead to errors after failover occurs. Note that this limitation should not affect your work because you typically use this parameter in a development environment only, not a high availability environment.
To configure the CHECK_FILE_MODIFICATION parameter for high availability:
This section describes procedures for troubleshooting possible issues with Fusion web applications at design time and after deployment.
When running or debugging an application that uses failover support (jbo.dofailover is enabled) within the JDeveloper environment, you are frequently starting and stopping the application server. The ADF failover mechanism has no way of knowing whether you stopped the server to simulate an application server failure, or whether you stopped it because you want to retest something from scratch in a fresh server instance. If you intend to do the latter, exit out of your browser before restarting the application on the server. This eliminates the chance that you will be confused by the correct functioning of the failover mechanism when you didn't intend to be testing that aspect of your application.
When you develop the Fusion web application in Oracle JDeveloper, the integrated development environment provides support for detecting potential high availability issues. The warnings that JDeveloper provides are generated by the audit framework and are triggered to appear in the JDeveloper source editors. The warnings the editors show are based on the audit rules for high availability applications.
The high availability audit rules that JDeveloper enables by default are:
ADF Controller Configuration - High Availability for ADF Scopes is not Enabled warns the developer that the adf-scope-ha-support flag in the adf-config.xml file is set is not set to true. This audit rule fires only when the <adf-controller-config> element is in the ADF application-level configuration file (adf-config.xml).
ADF Page Flows - Bean in Scope Map is Modified warns the developer when the some code calls a setter method on a bean to indicate that the code did not subsequently call the ControllerContext.markScopeDirty() method. This audit rule fire only when the adf-scope-ha-support flag in the adf-config.xml file is set to true.
ADF Page Flows - EL Bean is Modified warns the developer when some code evaluates an EL expression that mutates a bean to indicate that the code did not subsequently call the ControllerContext.markScopeDirty() method. This audit rule fire only when the adf-scope-ha-support flag in the adf-config.xml file is set to true.
ADF Page Flows - Managed Bean Class Not Serializable warns the developer that a managed bean has a non-serializable class defined in viewScope, pageFlowScope, or sessionScope. This audit rule fire only when the adf-scope-ha-support flag in the adf-config.xml file is set to true.
You can modify the high availability audit rule settings using the Preference dialog in JDeveloper. From the JDeveloper toolbar, choose Tools - Preferences, under Audit - Profiles expand ADF Controller Configuration or ADF Pages Flows and make the desired audit rule selections.
You can also trigger the audit by choosing Build - Audit project.jpr from the JDeveloper toolbar.
There are two actions to take if you encounter Fusion web application deployment issues: verify the JRF Runtime and verify the status of application deployments.
The first step to troubleshooting an Fusion web application deployment is to verify that the JRF Runtime is installed on the WebLogic Server domain. ADF applications require the JRF and ADF runtime. You cannot run ADF applications with a standalone WebLogic Server domain or just the WebLogic Server portion of the Application Development product; you must extend it with the JRF extension template.
For more information on the JRF Template, see "Oracle JRF and ADF Templates" in Domain Template Reference.
Fusion web applications deploy when the Managed Server first starts. Use the Administration Console to check that all application deployments were successful:
DOMAIN_HOME/servers/server_name/logs directory. Common issues include:Unavailability of external resources, such as database resources. Examine the error, fix it, and attempt to redeploy the application.
The appropriate applications or libraries are not targeted correctly to the right Managed Server or Cluster.
State Replication is most prominent in failover scenarios. A user working on one server may discover that, upon failover:
Windows may close or the state might reset.
Screens may require a reset.
The application may redirect to the logon screen.
To diagnose and troubleshoot state replication issues.