4 High Availability

This chapter describes the issues related to Oracle Fusion Middleware high availability.

The following topics are covered in this chapter:

4.1 Issues Pertaining to SOA BPEL Components

This section contains the following topic:

4.1.1 Using Deferred Value for completionPersistPolicy May Cause BPEL Component Failure

For SOA BPEL components, some instances may fail during RAC failover if you use the value Deferred for the completionPersistPolicy policy. If failure occurs, the following error appears: Error committing transaction.

Because a RAC failover can cause a mismatch between transactions on two threads, avoid using the value Deferred if the instance state is critical for the application.

4.2 Issues Pertaining to SOA Core Extension

This section contains the following topic:

4.2.1 Additional Web Server Configuration when Using SOA Core Extension

If you have Oracle HTTP Server as a front end, complete the following steps if you are configuring SOA Core Extension as part of a high availability or enterprise deployment.

To perform prerequisites for cluster installation:

  1. Open the Administration Console.

  2. Click View changes and Restart in the Change Center.

  3. Click Restart Checklist.

  4. Ensure that neither the Administration Server for the cluster nor any SOA servers for the cluster are on the restart checklist.

  5. If there are any servers listed, restart it.

If you are installing only the Foundation Pack on the cluster:

  1. Open the WebTier_HOME/instances/instances_name/config/OHS/ohs1/mod_wl_ohs.conf file.

  2. Add the following code:

    <Location /AIA>
SetHandler weblogic-handler
WebLogicCluster <machine1_hostname>:<port>,<machine2_hostname>:<port>
WLLogFile /tmp/web_log.log
</Location>
<Location /AIAValidationSystemServlet> 
SetHandler weblogic-handler 
WebLogicCluster <machine1_hostname>:<port>,<machine2_hostname>:<port>
WLLogFile /tmp/web_log.log
</Location> 
<Location  /MirrorServlet> 
SetHandler weblogic-handler 
WebLogicCluster <machine1_hostname>:<port>,<machine1_hostname>:<port>
WLLogFile  /tmp/web_log.log 
</Location>

  3. Restart the Oracle HTTP Server.

    After you set up a SOA cluster, the following entry is added:

    # UMS prefs
<Location /sdpmessaging/userprefs-ui>
 SetHandler weblogic-handler 
WebLogicCluster <machine1_hostname>:<port>,<machine2_hostname>:<port>
</Location>
sdpmessaging/

  4. Change the Location attribute to /sdpmessaging from /sdpmessaging/userprefs-ui

4.3 Issues Pertaining to Automatic Service Migration

This section contains the following topic:

4.3.1 Oracle User Messaging Service 12c (12.1.3) Does Not Support Automatic Service Migration

In enterprise deployments that take advantage of high availability, Oracle recommends that you configure Oracle BAM to use Automatic Service Migration, which migrates specific services to a different Managed Server in the cluster when a server fails.

However, in some scenarios where Oracle BAM is producing constant and intensive User Messaging Service (UMS) messages, a Managed Server failure might leave some alert messages stuck in the UMS queues. This is because UMS 12c (12.1.3) does not currently support Automatic Service Migration.

To workaround this issue, you can recover messages in the UMS queues by restarting the failed Oracle BAM Managed Server. To resume the appropriate capacity and load sustainability after a BAM server failure, you must do two things:

  • Restart the failed Managed Server.

  • Fail back the migrated services to the original Managed Server.

For more information, see "Failing Back Oracle BAM Services After Automatic Service Migration Occurs" in Enterprise Deployment Guide for Oracle SOA Suite.

If a BAM server restart is not compatible with your system's recovery time objectives (RTO), then you can configure UMS with Advanced Queuing (AQ) JMS instead of the default JMS provider. For more information, see Appendix B, "Configuring User Messaging Service with AQ JMS," in Administering Oracle User Messaging Service.