WebLogic Integration Solutions Best Practices FAQ

WebLogic Integration Application Recovery

The following section provides answers to questions about configuring WebLogic Integration applications for recovery. It contains the following topic:

Recovery Checklist

Recovery Checklist

This section answers the following questions:

What should I check to make sure my WebLogic Integration application is configured properly for recovery?

You should check to make sure your WebLogic Integration application is configured in the following manner:

An XA driver is configured in cgPool.
All JMS servers are targeted to a migratable target. (Migratable targets have the word migratable in the target name.)

Note: If you need to change the targeting of one or more JMS servers in an active cluster, you must restart the cluster after you make changes to the targeting configuration.

WLAI_DataSource is not pointing to cgPool. If it is, either delete WLAI_DataSource or retarget it to another pool.

Note: WLAI_DataSource pointing to cgPool was the default configuration for domains generated by the Configuration Wizard in WebLogic Integration 8.1 SP1. This is not a problem for domains generated in WebLogic Integration 8.1 SP2.

For more information on retargeting WLAI_DataSource to another pool, see "Guidelines for Changing to an XA Configuration" in How Do I... in Creating WebLogic Configurations Using the Configuration Wizard.

The WLI Admin component of WLI System EJBs is targeted to the cluster. You can verify the targeting of WLI Admin by inspecting its configuration in the config.xml file for the WLI System EJBs application.

Note: WLI Admin can be targeted to the cluster only when JMS servers are targeted to migratable targets.

Retries and retry intervals are appropriate. Retries multiplied by retry interval should exceed the time it takes for JTA recovery to run.

If you need to tune your retries and retry intervals, you have the following choices:

Carefully set retry-count and retry-interval in your JPDs.
Set the retry-count and retry-interval of the async and error queues for each JPD project (WebApp).

Note: This will break explicit retry settings on the JPD, but it is the easiest and recommended approach.

For more details, see JMSQueue in the WebLogic Server Configuration Reference.

JTA attribute TimeoutSeconds in the config.xml file is set to a value less than the value of the JDBCConnectionPool.XA TransactionTimeout attribute for XA connection pools.

For more information about TimeoutSeconds, see JTA in the WebLogic Server Configuration Reference.

JTA attribute MaxTransactions in the config.xml file is set to a value large enough to accommodate the number of simultaneous transactions that could occur on a server during recovery. For transaction intensive applications, you should increase the value of this attribute from the default setting.

For more information about MaxTransactions, see Domain-->Configuration-->JTA in the WebLogic Server Administration Console Online Help.

JDBCConnectionPool attribute MaxCapacity in the config.xml file is set to a value greater than the value of the execute queue ThreadCount attribute.

For more information about MaxCapacity, see JDBCConnectionPool in the WebLogic Server Configuration Reference.
For information about Server ThreadCount, see "Tuning the Default Execute Queue Threads" in Tuning WebLogic Server in WebLogic Server Performance and Tuning.

When using Oracle, the repository tables dba_2pc_pending, dba_2pc_neighbors, and dba_pending_transactions must have the right permissions for recovery to be called. If they do not, you will get a database error and recovery will fail.

How long should I wait to start recovery?

It can take several minutes for in-doubt transactions to show up in Oracle There may be a race if recovery has started prior to Oracle detecting the loss of the TM. Wait several minutes before starting recovery—either by restarting the server or by doing a JTA migration.

After initiating recovery, if you check the Oracle dba_2pc_pending table and see a record associated with the failed server that has a timestamp prior to initiating recovery, recovery will fail. Restart the server.