Skip Headers
Oracle® Fusion Applications Administrator's Guide
11g Release 6 Refresh 4 (11.1.6)

Part Number E14496-14
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

A High Availability for Oracle Fusion Middleware Extensions for Applications

This appendix describes high availability considerations for Oracle Fusion Middleware Extensions for Applications (Applications Core). For more information about Oracle Fusion Applications high availability, see Chapter 19. For more information on Oracle Fusion Middleware Extensions for Applications, see the "Overview of Oracle Fusion Middleware Extensions for Applications" section in the Oracle Fusion Applications Concepts Guide.

High availability refers to the ability of users to access a system without loss of service. Oracle Fusion Middleware has an extensive set of high availability features, which protect its components and applications from unplanned down time and minimize planned downtime. For more information about Oracle Fusion Middleware high availability, see Oracle Fusion Middleware High Availability Guide.

This appendix includes the topic, Section A.1, "How Oracle Fusion Middleware Extensions Components Use Fusion Middleware Components for High Availability and Failover."

A.1 How Oracle Fusion Middleware Extensions Components Use Fusion Middleware Components for High Availability and Failover

With the approach of only building with use of other existing or lower level components, Applications Core obtains complete high availability without the need to implement any high availability features itself. However, it is then important to know what the base features each component is built upon, to understand how it behaves for high availability.

A.1.1 Oracle Metadata Repository

Applications Core relies almost entirely on MDS for storage of metadata used by Customization, Flexfields, and Menus. It is very important that MDS is configured for high availability. MDS for these operations should be based on a database rather than file based MDS architecture.

The MDS database-based repository can be configured for high availability Oracle database access. With this configuration, failure detection, recovery, and retry by MDS, as well as by the WebLogic infrastructure, result in the application's read-only MDS operations being protected from Oracle RAC database planned and unplanned downtimes. For more information about configuring multi data sources for MDS repositories, see "Configuring Multi Data Sources for MDS Repositories" in the Oracle Fusion Middleware High Availability Guide.

A.1.2 Oracle Application Development Framework

Most runtime state information of an application is held in Oracle ADF. Applications Core does not create its own components, so it can achieve failover support by following the ADF rules for high availability development. When you are designing an application to run in a clustered environment, you must:

  • Ensure that all managed beans with a life span longer than one request are serialized. When the Fusion web application runs in a clustered environment, a portion of the application's state is serialized and copied to another server or a data store at the end of each request so that the state is available to other servers in the cluster.

  • Ensure that Oracle ADF is aware of changes to managed beans stored in ADF scopes (view scope and page flow scope) and enable the tracking of changes to ADF memory scopes. When a value within a managed bean in either view scope or page flow scope is modified, the application needs to notify Oracle ADF so that it can ensure the bean's new value is replicated.

For more information about configuring high availability for ADF, see the "Configuring High Availability for Oracle ADF and WebCenter Applications" in the Oracle Fusion Middleware High Availability Guide.

A.1.3 WebLogic Server Failover for Session Content

Applications Core Session Management does cache the ApplSession using the HttpSession, but it is marked as non-serializable so that it does not get persisted in the event of failover/replication. The ApplSession will be re-established from the session cookie from the client that is set when the session is first created.