Administration Console Online Help

Configure migratable targets
for the JTA Transaction Recovery Service

Before you begin

Before you can migrate the JTA Transaction Recovery Service (TRS) 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 server
migration in a cluster.

A migratable target is a list of
servers in the cluster that can potentially host a pinned service, such
as the JTA Transaction Recovery Service. Migratable targets control the
servers to which you can migrate a service, either manually or
automatically. For the TRS, you must specify the list of candidate
servers that have access to the current server's transaction log files
(stored in the default WebLogic store). For automatic migration, you
must select the appropriate migration policy. You can also define the
appropriate pre-migration and post-migration scripts to perform any
unmounting and mounting of shared storage, as needed.

To configure the migratable target servers for JTA Transaction
Recovery Service migration:

If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit (see Use the Change Center).

Service Migration Policy -- change
the Manual Service Migration Only default to
Auto-Migrate Failure Recovery Services if you
want to have the JTA Transaction Recovery Service automatically
migrated from an unhealthy server instance to a healthy server
instance, with the help of the server health monitoring
services.

User Preferred Server -- select the
preferred server in the cluster that you want to associate the
migratable target with.

Constrained Candidate Servers --
select the servers you want to use as a the JTA Transaction Recovery
Service server backup and move them to the
Chosen list.

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.

Note: For JTA, you must specify the list of candidate
servers that have access to the current server's transaction log
files (stored in the default WebLogic file store).