Administration Console Online Help

Previous Next Open TOC in new window
Content starts here

Configure automatic migration of the JTA Transaction Recovery Service

Before you begin

Before you can configure the JTA Transaction Recovery Service (TRS) to automatically migrate to another server in the cluster, you must configure the managed servers in the cluster for migration, including assigning managed servers to a machine and configuring Node Manager. See Configure the JTA Transaction Recovery Service for migration.

You can specify to have the JTA TRS automatically migrated from an unhealthy server instance to a healthy server instance, with the help of the server health monitoring services.

To configure the automatic migration of the JTA TRS:

  1. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit (see Use the Change Center).
  2. In the Domain Structure tree, expand Environment, and then select Clusters.
  3. On the Summary of Clusters page, select the cluster you want to modify.
  4. Go to the Configuration > Migration page.
  5. Modify the Migration Basis field as follows:
    • Database -- requires that Data Source For Automatic Migration field is set with a valid JDBC system resource. It implies that there is a table created on that resource that migrating servers will use for leasing. Node Manager is required only if pre-migration/post-migration scripts are not defined.
    • Consensus -- requires that all servers that are migratable, or which could host an auto-migratable target, have a Node Manager associated with them.
  6. Under Environment, select Servers.
  7. Go to the Configuration > Migration page.
  8. In the JTA Migration Configuration section, select the Automatic JTA Migration Enabled check box.
  9. Use the JTA Candidate Servers box to select the servers you want to use as the JTA TRS server backup and move them to the Chosen list.

    Note: You should select candidate servers that have access to the current server's transaction log files (stored in the default WebLogic file store). If no candidate servers are chosen , then any server within the cluster can be chosen as a candidate server.

  10. Optionally, specify whether you are providing pre-migration and post-migration scripts to perform any dismounting and mounting of the shared storage, as needed:
    • Pre-Migration Script Path -- the path to the pre-migration script to run before a migratable target is actually activated.
    • Post-Migration Script Path -- the path to the post-migration script to run after a migratable target is fully deactivated.
    • Post-Migration Script Failure Cancels Automatic Migration -- specifies whether or not a failure during execution of the post-deactivation script is fatal to the migration.
    • Allow Post-Migration Script To Run On a Different Machine -- specifies whether or not the post-deactivation script is allowed to run on a different machine.

    The pre/post-migration scripts must be located in the MIDDLEWARE_HOME/user_projects/domains/mydomain/bin/service_migration directory, where mydomain is a domain-specific directory, with the same name as the domain. For your convenience, sample pre-migration and post-migrations scripts are provided in this directory.

    For more information about these fields, refer to Configuration Options.

  11. Click Save.
  12. To activate these changes, in the Change Center of the Administration Console, click Activate Changes.
    Not all changes take effect immediately—some require a restart (see Use the Change Center).

Back to Top