Service Migration 8-3
8.1.1.2 JTA Transaction Recovery Service
The Transaction Recovery Service automatically attempts to recover transactions on system startup by parsing all transaction log records for incomplete transactions and
completing them. For detailed information, see Transaction Recovery After a Server Fails in Programming JTA for Oracle WebLogic Server.
8.1.1.3 User-defined Singleton Services
Within an application, you can define a singleton service that can be used to perform tasks that you want to be executed on only one member of a cluster at any give time.
See Section 8.8, Automatic Migration of User-Defined Singleton Services.
8.1.2 Understanding Migratable Targets In a Cluster
You can configure JMS and JTA services for high availability by using migratable targets. A migratable target is a special target that can migrate from one server in a
cluster to another. As such, a migratable target provides a way to group migratable services that should move together. When the migratable target is migrated, all
services hosted by that target are migrated.
In order to configure a migratable JMS service for migration, it must be deployed to a migratable target. A migratable target specifies a set of servers that can host a target,
and can optionally specify a user-preferred host for the services and an ordered list of candidate backup servers should the preferred server fail. Only one of these servers
can host the migratable target at any one time.
Once a service is configured to use a migratable target, then the service is independent from the server member that is currently hosting it. For example, if a JMS server with a
deployed JMS queue is configured to use a migratable target, then the queue is independent of when a specific server member is available. In other words, the queue
is always available when the migratable target is hosted by any server in the cluster.
An administrator can manually migrate pinned migratable services from one server instance to another in the cluster, either in response to a server failure or as part of
regularly scheduled maintenance. If you do not configure a migratable target in the cluster, migratable services can be migrated to any WebLogic Server instance in the
cluster. See the
Section 8.5, Roadmap for Configuring Manual Migration of JMS-related Services.
8.1.2.1 Policies for Manual and Automatic Service Migration
A migratable target provides migration policies that define whether the hosted services will be manually migrated the system default or automatically migrated
from an unhealthy hosting server to a healthy active server with the help of the health monitoring subsystem. There are two types of automatic service migration policies, as
described in the following sections.
8.1.2.1.1 Manual Migration When a migratable target uses the manual policy the
system default, an administrator can manually migrate pinned migratable services from one server instance to another in the cluster, either in response to a server failure
or as part of regularly scheduled maintenance.
See the Section 8.5, Roadmap for Configuring Manual Migration of JMS-related
Services.
8.1.2.1.2 Exactly-Once This policy indicates that if at least one Managed Server in the
candidate list is running, then the service will be active somewhere in the cluster if servers fail or are shut down either gracefully or forcibly. It is important to note that
8-4 Using Clusters for Oracle WebLogic Server
this value can lead to target grouping. For example, if you have five exactly-once migratable targets and only boot one Managed Server in the cluster, then all five
targets will be activated on that server.
Example use-case for JMS servers: A domain has a cluster of three Managed Servers, with one JMS server deployed on a
member server in the cluster. Applications deployed to the cluster send messages to the queues targeted to the JMS server. MDBs in another domain drain the queues
associated with the JMS server. The MDBs only want to drain from one set of queues, not from many instances of the same queue. In other words, this environment uses
clustering for scalability, load balancing, and failover for its applications, but not for its JMS server. Therefore, this environment would benefit from the automatic migration of
the JMS server as an exactly-once service to an available cluster member.
See the Section 8.3, Roadmap for Configuring Automatic Migration of JMS-related
Services.
8.1.2.1.3 Failure-Recovery This policy indicates that the service will only start if its
user-preferred server UPS is started. If an administrator manually shuts down the UPS, either gracefully or forcibly, then a failure-recovery service will not migrate.
However, if the UPS fails due to an internal error, then a failure-recovery service will be migrated to another candidate server. If such a candidate server is unavailable
due to a manual shutdown or an internal failure, then the migration framework will first attempt to reactivate the service on its UPS server. If the UPS server is not
available at that time, then the service will be migrated to another candidate server.
Example use-case for JMS servers: A domain has a cluster of three Managed Servers, with a JMS server on each member
server and a distributed queue member on each JMS server. There is also an MDB targeted to the cluster that drains from the distributed queue member on the local
server member. In other words, this environment uses clustering for overall scalability, load balancing, and failover. Therefore, this environment would benefit from the
automatic migration of a JMS server as an failure-recovery service to a UPS member.
See the Section 8.3, Roadmap for Configuring Automatic Migration of JMS-related
Services.
Tip: As a best practice, a migratable target hosting a path service
should always be set to exactly-once, so if its hosting server member fails or is shut down, the path service will automatically
migrate to another server, and so will always be active in the cluster.
Caution: If a server is also configured to use the automatic
whole-server migration framework, which will shut down the server when its expired lease cannot be renewed, then any
failure-recovery services also configured on that server will not automatically migrate no matter how the server is manually
shutdown by an administrator for example, killed versus graceful shutdown. For more information, see
Section 7.4, Automatic Whole Server Migration.
Service Migration 8-5
8.1.2.2 Options For Attempting to Restart Failed Services Before Migrating
