X

Proactive insights, news and tips from Oracle WebLogic Server Support. Learn Oracle from Oracle.

  • June 20, 2019

Configuring WebLogic Server JTA Automatic Service Migration with Dynamic Clusters Using WLST and REST

Alex Somogyi
Consulting Member of Technical Staff

WebLogic Server JTA service migration allows for in-progress transactions that are coordinated by a clustered server that fails to be recovered and resolved by another cluster member.  This capability helps to resolve transactions quickly, potentially reducing the amount of time that resource manager locks are held that could impede other transactions.

There are two types of clusters supported by WebLogic Server, configured and dynamic.  Configured clusters consist of pre-defined Server instances that reference a cluster configuration.  Dynamic clusters utilize a Server Template to create new cluster members at runtime in response to administrative commands, or performance-based rules, and is the default clustering model used in Kubernetes WebLogic Operator environments.  For additional details about WebLogic Server clustering, refer to “Administering Clusters on Oracle WebLogic Server“.

JTA service migration can be configured to automatically fail over when a server terminates by setting the JTA Migratable Target - Migration Policy attribute on the clustered servers to either “failure-recovery” or “shutdown-recovery”.  By default, all servers in the cluster are considered candidates for migration of any server’s transaction recovery service.  For configured clusters, a server can restrict the set of cluster members that can process its recovery service by assigning a subset of the cluster members to the Constrained Candidate Servers attribute.    

The WebLogic Server Administration Console exposes JTA service migration configuration attributes on the Server > Configuration > Migration page.  The following screenshot shows a portion of the Server Migration page for a configured cluster containing two Managed Servers (Server-1 and Server-2) where the Migration Policy attribute is set to Failure Recovery, and the Strict Ownership Check attribute is set to true.

To configure JTA auto-migration in a dynamic cluster, it is necessary to set the JTA Migratable Target attributes on the Cluster Server Template.  However, in WebLogic Server versions 12.2.1.3.0 and earlier, the JTA Migratable Target fields are not exposed on the Administration Console’s Server Template > Configuration > Migration page (see the Administration Console screenshot below).  Due to the lack of Console support, an administration client or API, such as WLST or REST, is required to make the necessary configuration changes to the Server Template JTA Migratable Target.

 

 

There are a couple of additional points regarding JTA service migration configuration with dynamic clusters.  First, it is not possible to define a constrained list of candidate servers.  All members of the dynamic cluster are considered candidates for failover.  Finally, if the dynamic cluster’s Migration Basis attribute is set to “Database”, then the Data Source for Automatic Migration attribute must also be set.  This attribute is available on the Administration Console Cluster > Configuration > Migration page.

For additional details on configuring JTA automatic service migration, refer to the WebLogic Server documentation section “Roadmap for Configuring Automatic Migration of the JTA Transaction Recovery Service“.

Examples

The following examples show how to set the JTA auto-migration fields on a cluster server template using WLST and REST endpoints.  The scripts operate on a domain that contains a dynamic cluster with a server template named “DynCluster-Template”.  Both examples set the JTA Migration Policy and Strict Ownership Check attributes to “failure-recovery” and “true” respectively. 

Note that in both scripts, WebLogic Server administrative credentials need to be substituted for username and password, and the Administration Server’s address and port number should be specified in place of host:7001.  Also substitute the actual cluster server template name for DynCluster-Template.

WLST

connect("username","password","t3://host:7001")
edit()
startEdit()
cd('/ServerTemplates/DynCluster-Template/JTAMigratableTarget/DynCluster-Template')
cmo.setMigrationPolicy('failure-recovery')
cmo.setStrictOwnershipCheck(true)
activate()

REST

curl -v --user username:password -H X-Requested-By:MyClient \
-H Accept:application/json -H Content-Type:application/json \
-d "{}" -X POST "http://host:7001/management/weblogic/latest/edit/changeManager/startEdit"

curl -v --user username:password -H X-Requested-By:MyClient \
-H Accept:application/json -H Content-Type:application/json \
-d "{ 'migrationPolicy': 'failure-recovery', 'strictOwnershipCheck': true }" \
-X POST "http://host:7001/management/weblogic/latest/edit/serverTemplates/DynCluster-Template/JTAMigratableTarget"

curl -v --user username: password -H X-Requested-By:MyClient \
-H Accept:application/json -H Content-Type:application/json \
-d "{}" -X POST "http://host:7001/management/weblogic/latest/edit/changeManager/activate"

Resulting Configuration

Each of the example scripts will modify the domain configuration such that the Server Template JTA Migratable Target element contains the updated Migration Policy and Strict Ownership Check attributes.

  <server-template>
    <name>DynCluster-Template</name>
    <ssl>
      <listen-port>8100</listen-port>
    </ssl>
    <machine xsi:nil="true"></machine>
    <listen-port>7100</listen-port>
    <cluster>DynCluster</cluster>
    <web-server>
      <web-server-log>
        <number-of-files-limited>false</number-of-files-limited>
      </web-server-log>
    </web-server>
    <administration-port>9002</administration-port>
    <jta-migratable-target>
      <cluster>DynCluster</cluster>
      <migration-policy>failure-recovery</migration-policy>
      <strict-ownership-check>true</strict-ownership-check>
    </jta-migratable-target>
  </server-template>

Summary

This article showed how to enable JTA automatic service migration in a dynamic cluster by using WLST and REST APIs to update the necessary Server Template configuration attributes.   JTA automatic service migration with dynamic clusters provides the ability for applications to scale dynamically based on runtime metrics while potentially improving throughput and reducing the risk of data loss in the event of server failure.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.