1. Developing JTA Applications for Oracle WebLogic Server
  2. Managing Transactions

3 Managing Transactions

Learn about administration tasks that are used to manage transactions. These tasks include monitoring transactions, handling heuristic completions, how to abandon a transaction, resolving in-flight transactions, and transaction recovery.

Monitor transactions on a server using statistics and monitoring facilities. Use the Administration Console to configure these features and to display the resulting output.

Monitoring Transactions

Monitor transactions for each server in the domain using the Administration Console. Transaction statistics are displayed for a specific server, not the entire domain.

For instructions, see the following pages in the Oracle WebLogic Server Administration Console Online Help:

Handling Heuristic Completions

A heuristic completion (or heuristic decision) occurs when a resource makes a unilateral decision during the completion stage of a distributed transaction to commit or rollback updates. This can leave distributed data in an indeterminate state. Network failures or resource timeouts are possible causes for heuristic completion.

In the event of an heuristic completion, one of the following heuristic outcome exceptions may be thrown:

  • HeuristicRollback—one resource participating in a transaction decided to autonomously rollback its work, even though it agreed to prepare itself and wait for a commit decision. If the Transaction Manager decided to commit the transaction, the resource's heuristic rollback decision was incorrect, and might lead to an inconsistent outcome since other branches of the transaction were committed.

  • HeuristicCommit—one resource participating in a transaction decided to autonomously commit its work, even though it agreed to prepare itself and wait for a commit decision. If the Transaction Manager decided to rollback the transaction, the resource's heuristic commit decision was incorrect, and might lead to an inconsistent outcome since other branches of the transaction were rolled back.

  • HeuristicMixed—the Transaction Manager is aware that a transaction resulted in a mixed outcome, where some participating resources committed and some rolled back. The underlying cause was most likely heuristic rollback or heuristic commit decisions made by one or more of the participating resources.

  • HeuristicHazard—the Transaction Manager is aware that a transaction might have resulted in a mixed outcome, where some participating resources committed and some rolled back. But system or resource failures make it impossible to know for sure whether a Heuristic Mixed outcome definitely occurred. The underlying cause was most likely heuristic rollback or heuristic commit decisions made by one or more of the participating resources.

When an heuristic completion occurs, a message is written to the server log. Refer to your database vendor documentation for instructions on resolving heuristic completions.

Some resource managers save context information for heuristic completions. This information can be helpful in resolving resource manager data inconsistencies. If the ForgetHeuristics attribute is selected (set to true) on the JTA panel of the WebLogic Server Administration Console, this information is removed after an heuristic completion. When using a resource manager that saves context information, you may want to set the ForgetHeuristics attribute to false.

Moving a Server

A server instance is identified by its URL (IP address or DNS name plus the listening port number). Changing the URL by moving the server to a new machine or changing the Listening Port of a server on the same machine effectively moves the server so the server identity may no longer match the information stored in the transaction logs.

  • If the new server has the same URL as the old server, the Transaction Recovery Service searches all transaction log files for incomplete transactions and completes them as described in Transaction Recovery Service Actions After a Crash.

  • When the coordinator server is in the same domain as the sub-coordinator and the server URL changes, the coordinator queries the Administration Server for the new URL of the sub-coordinator and the propagation of any new transactions and any transactions that are committing or rolling back use the new URL. Transaction branches for the sub-coordinator with pending commit records stored in the coordinator's transaction log files before the URL change are unrecoverable. If you wish, you can delete the transaction log files of the coordinator. This step prevents the Transaction Recovery Service from attempting to resolve these transactions until the value of the AbandonTimeoutSeconds parameter is exceeded. See Abandoning Transactions and How to Remove Transaction Records.

  • When transactions span multiple domains and if a server acting as a remote transaction sub-coordination fails and its URL changes, any ongoing transactions do not complete (commit or are rolled back) because the coordinator is unable to communicate with the remote domain's Admin server. The coordinator is unable to contact the sub-coordinator using the new URL and any ongoing transactions fail. The coordinator attempts the commit or rollback request until the AbandonTimeoutSeconds value is exceeded. See Abandoning Transactions . Any new transactions fail because the coordinator cannot contact the sub-coordinator. The TLogs of the coordinator and sub-coordinators, excluding the moved server domain, must be deleted. See How to Remove Transaction Records.

Oracle recommends configuring server instances using DNS names rather than IP addresses to promote portability.

If you move a server to a new machine, follow the instructions for Recovering Transactions For a Failed Non-Clustered Server.

Abandoning Transactions

You can choose to abandon incomplete transactions after a specified amount of time.

In the two-phase commit process for distributed transactions, the transaction manager coordinates all resource managers involved in a transaction. After all resource managers vote to commit or rollback, the transaction manager notifies the resource managers to act—to either commit or rollback changes. During this second phase of the two-phase commit process, the transaction manager continues to try to complete the transaction until all resource managers indicate that the transaction is completed. Using the AbandonTimeoutSeconds attribute, set the maximum time, in seconds, that a transaction manager persists in attempting to complete a transaction during the second phase of the commit protocol. The default value is 86400 seconds, or 24 hours. After the abandon transaction timer expires, no further attempt is made to resolve the transaction with any resources that are unavailable or unable to acknowledge the transaction outcome. If the transaction is in a prepared state before being abandoned, the transaction manager rolls back the transaction to release any locks held on behalf of the abandoned transaction and writes an heuristic error to the server log.

For instructions on how to set the AbandonTimeoutSeconds attribute, see Configure JTA in the Oracle WebLogic Server Administration Console Online Help.

Note:

It is not recommended to change the default AbandonTimeoutSeconds attribute to a small value. When a global transaction is abandoned, resource manager transaction branches could be left pending, which would require manual intervention to resolve.

Transaction Completion Timeout

When an application or server component instructs a transaction to commit or rollback, the commit or rollback API will block while the transaction manager processes the two-phase commit protocol. If the transaction is unable to complete within a period of time (up to two minutes by default) a SystemException will be raised. A SystemException is non-deterministic relative to transaction outcome so an application environment must provide special exception handling for this case which often involves manually analyzing the transaction activity and state of the resources involved in the transaction. The period of time waiting for a transaction to complete can be changed by setting the completion-timeout-seconds attribute.

For configuration information, see:

Note:

The completion-timeout-seconds attribute does not apply to imported transactions such as JCA transactions or to recovering transactions.

If transactions are taking a long time to complete the two-phase commit protocol then it could indicate a problem with server or resource manager participants. Viewing the current active transactions and server statistics on each of the server participants could help identify the cause of the transaction completion delays, see Monitoring Transactions.

Manually Resolving Current (Inflight) Transactions

If a transaction does not complete normally due to system or network failures, there may be locks held on behalf of the pending transaction that may inhibit the progress of other transactions. You can wait for the WebLogic Server Transaction Manager to remove the transaction from its internal data structures, or you can manually resolve "stuck" transactions.

After the Abandon Timeout period has elapsed, the WebLogic Server Transaction Manager removes the transaction from its internal data structures and writes a heuristic error to the server log. However, to manually resolve a transaction, you view current (inflight) transactions for a server from the Server>Monitoring>JTA tab and then view details about a specific transaction by clicking the transaction id. You can then force a commit or a rollback, depending on the status of the transaction. For more information, see View current transactions in Oracle WebLogic Server Administration Console Online Help.

Note:

It is possible for a transaction to have different states at different servers. For instance, a transaction may have been committed at the coordinating server, but a remote participant may not have received the commit instruction.

The following table provides information on transaction status and resolution options.

Table 3-1 Transaction Status Definitions and Manual Resolution Options

Status Definition Forced Commit? Forced Rollback?

Active

The application is processing the transaction. The transaction has not yet reached the two-phase commit processing.

  

Y

Preparing

Corresponds to the interval between when the transaction manager starts the javax.transaction.Synchronization beforeCompletion() callback processing, through the first phase of the 2PC protocol, and up to the point when all participants have responded, "ready to commit."

 

Y

Prepared

The interval between when all participants have responded to prepare up to the commit point (commit log record is flushed to disk) or to the initiation of rollback processing.

Y

Y

Committing

The time from when the commit decision is made up to the point when all participants have been informed of the outcome and the javax.transaction.Synchronization afterCompletion() callback processing has completed.

Y

  

Committed

The transaction has been committed. It is likely that heuristics exists, otherwise the transaction would have been completed and would not have been displayed in the list of current transactions.

Y

  

Rolling Back

This state occurs from the point when rollback processing is initiated up to the point when all participants have been instructed to rollback and the javax.transaction.Synchronization afterCompletion() callback processing has completed.

 

Y

Rolled Back

The transaction has been rolled back. It is likely that heuristics exists, otherwise the transaction would have been destroyed and would not have been displayed in the list of current transactions.

  

Y

Marked Roll Back

The transaction has been marked for rollback, perhaps as a result of a setRollbackOnly operation.

 

Y

No Transaction

      

Unknown

Current status cannot be determined.

Y

Y

Manual Commit and Rollback Options

To manually resolve a transaction, you can choose from the following options. Options are restricted as described in Table 3-1.

  • Force Local Commit—Each participating resource that is registered on the server is issued a commit operation for the specified transaction and the transaction will be removed from the local transaction manager's data structures. If the local server is the coordinator for the transaction, the commit record is released. See Force local commit in Oracle WebLogic Server Administration Console Online Help.

  • Force Global Commit—A local commit operation is attempted at each participating server for the specified transaction. If this option is invoked on a non-coordinating server, the coordinator will be contacted to process the operation. The coordinating server will issue asynchronous requests to each participant server. See Force global commit in Oracle WebLogic Server Administration Console Online Help.

  • Force Local Rollback—Each participating resource that is registered on the local server is issued a rollback operation for the specified transaction. The transaction will then be removed from the local transaction manager's data structures. See Force local rollback in Oracle WebLogic Server Administration Console Online Help.

  • Force Global Rollback—A local rollback operation is attempted at each participating server for the specified transaction. If this option is invoked on a non-coordinating server, the coordinator will be contacted to process the operation. The coordinating server will issue asynchronous requests to each participant server. See Force global rollback in Oracle WebLogic Server Administration Console Online Help.

    Note:

    When you select any of these options, WebLogic Server writes entries to the server log.

The difference between the Local and Global options is that Local options act only upon the current server resources (resources on the server that you select in the navigation tree in the left pane of the WebLogic Server Administration Console), whereas the Global options attempt to perform the operation across all participating servers. If a Global operation is invoked for a transaction that is not coordinated by the local server then an attempt will be made to contact the coordinator of the transaction in order to perform the operation. If the coordinator cannot be reached, the operation will fail with a javax.transaction.SystemException.

In the case where a transaction may have been committed at the coordinating server (committing status), but a remote participant did not receive the commit instruction (prepared status). You can force a local commit on the remote participant to complete the transaction. In this case it is possible to force a rollback on the remote participant since its transaction state will still be prepared, but the transaction will complete heuristically. If you try to force a global rollback, the operation will fail because the state at the coordinator is committing. You cannot roll back a transaction with the committing status.

Transaction Recovery After a Server Fails

The WebLogic Server transaction manager is designed to recover from system crashes with minimal user intervention. The Transaction Recovery Service provided by WebLogic Server makes every effort to resolve transaction branches that are prepared by resource managers with a commit or roll back, even after multiple crashes or crashes during recovery.

To facilitate recovery after a crash, the Transaction Recovery Service automatically attempts to recover transactions on system startup. On startup, the Transaction Recovery Service parses all transaction log records for incomplete transactions and completes them as described in Transaction Recovery Service Actions After a Crash.

Because the Transaction Recovery Service is designed to gracefully handle transaction recovery after a crash, Oracle recommends that you attempt to restart a crashed server and allow the Transaction Recovery Service to handle incomplete transactions.

If a server crashes and you do not expect to be able to restart it within a reasonable period of time, you may need to take action. Procedures for recovering transactions after a server failure differ based on your WebLogic Server environment. For a non-clustered server, you can manually move the server (with the default persistent store DAT file) to another system (machine) to recover transactions. See Recovering Transactions For a Failed Non-Clustered Server . For a server in a cluster, you can manually migrate the whole server or the Transaction Recovery Service to another server in the same cluster. Migrating the Transaction Recovery Service involves selecting a server with access to the transaction logs to recover transactions, and then migrating the service using the WebLogic Server Administration Console or the WebLogic command-line interface.

Note:

For non-clustered servers, you can only move the entire server to a new system. For clustered servers, you can migrate the entire server or temporarily migrate the Transaction Recovery Service.

For more information about migrating the Transaction Recovery Service, see Recovering Transactions For a Failed Clustered Server. For more information about clusters, see Administering Clusters for Oracle WebLogic Server.

The following sections provide information on how to recover after a failure:

Transaction Recovery Service Actions After a Crash

When you restart a server after a crash or when you migrate the Transaction Recovery Service to another (backup) server, the Transaction Recovery Service does the following:

  • Complete transactions ready for second phase of two-phase commit

    For transactions for which a commit decision has been made but the second phase of the two-phase commit process has not completed (transactions recorded in the transaction log), the Transaction Recovery Service completes the commit process.

  • Resolve prepared transactions

    For transactions that the transaction manager has prepared with a resource manager (transactions in phase one of the two-phase commit process), the Transaction Recovery Service must call XAResource.recover() during crash recovery for each resource manager and eventually resolve (by calling the commit(), rollback(), or forget() method) all transaction IDs returned by recover().

  • Report heuristic completions

    If a resource manager reports a heuristic exception, the Transaction Recovery Service records the heuristic exception in the server log and calls forget() if the Forget Heuristics configuration attribute is enabled. If the Forget Heuristics configuration attribute is not enabled, refer to your database vendor's documentation for information about resolving heuristic completions. See Handling Heuristic Completions .

Note:

Prior to WebLogic Server 12.2.1.3.0, when a WebLogic JMS resource was enlisted in a subordinate domain in a transaction that spanned domains, and if the WebLogic JMS resource later migrated to a different server before the completion of the transaction, then the automatic transaction recovery of the migrated WebLogic JMS resource and transactions would occur only after the WebLogic JMS resource was migrated back to its original location. This recovery is now supported, however, this recovery does not provide continuity of existing inflight transactions. In case of migration due to server crash, or if WebLogic JMS did not shutdown gracefully then there is a possibility of some exceptions occurring and leading to transactions rolling back.

The Transaction Recovery Service provides the following benefits:

  • Maintains consistency across resources

    The Transaction Recovery Service handles transaction recovery in a consistent, predictable manner: For a transaction for which a commit decision has been made but is not yet committed before a crash, and XAResource.recover() returns the transaction ID, the Transaction Recovery Service consistently calls XAResource.commit(); for a transaction for which a commit decision has not been made before a crash, and XAResource.recover() returns its transaction ID, the Transaction Recovery Service consistently calls XAResource.rollback(). With consistent, predictable transaction recovery, a transaction manager crash by itself cannot cause a mixed heuristic completion where some branches are committed and some are rolled back.

  • Persists in achieving transaction resolution

    If a resource manager crashes, the Transaction Recovery Service must eventually call commit() or rollback() for each prepared transaction until it gets a successful return from commit() or rollback(). The attempts to resolve the transaction can be limited by setting the AbandonTimeoutSeconds configuration attribute. See Abandoning Transactions .

Clustering Failover When Using Apache With the WebLogic Proxy Plug-in

When using Apache with the WebLogic Proxy plug-in as the front-end for a cluster, the plug-in uses several configuration parameters to determine how long to wait for connections to the WebLogic Server host and, after a connection is established, how long the plug-in waits for a response:

  • Verify the setting of the Apache idempotent flag. When idempotent is set to ON, and if the servers do not respond within the specified WLIOTimeoutSecs value, the plug-ins fail over. The plug-ins also fail over if idempotent is set to ON and the servers respond with an error such as READ_ERROR_FROM_SERVER. If set to OFF, the plug-ins do not fail over. See Parameters for Web Server Plug-Ins in Using Web Server 1.1 Plug-Ins with Oracle WebLogic Server.

  • Verify the setting of WebLogic Proxy Plug-in retry mechanism; for example, whether the maximum number of retries allowed is equal to the ConnectTimeoutSecs value divided by the ConnectRetrySecs value. See Failover, Cookies, and HTTP Sessions in Using Web Server 1.1 Plug-Ins with Oracle WebLogic Server.

Recovering Transactions For a Failed Non-Clustered Server

To recover transactions for a failed server, follow these steps:

  1. Move (or make available) the persistent store DAT file (which contains all transaction log records) from the failed server to a new server.
  2. Set the path for the default persistent store with the path to the data file. See Setting the Path for the Default Persistent Store .
  3. Start the new server. The Transaction Recovery Service searches all transaction log files for incomplete transactions and completes them as described in Transaction Recovery Service Actions After a Crash.

When moving transaction log records after a server failure, make all transaction log records available on the new machine before starting the server there. Otherwise, transactions in the process of being committed at the time of a crash might not be resolved correctly, resulting in application data inconsistencies. Accomplish this by storing persistent store data files on a dual-ported disk available to both machines. As in the case of a planned migration, update the default file store directory attribute with the new path before starting the server if the pathname is different on the new machine.

Note:

The Transaction Recovery Service is designed to gracefully handle transaction recovery after a crash. Oracle recommends that you attempt to restart a crashed server and allow the Transaction Recovery Service to handle incomplete transactions, rather than move the server to a new machine.

Recovering Transactions For a Failed Clustered Server

When a clustered server fails, you have the following options for recovering transactions:

Server Migration

For clustered servers, WebLogic Server enables you to migrate a failing server to a new machine, including the Transaction Recovery Service. When the server migrates to another machine, it must be able to locate the transaction log records to complete or recover transactions. Transaction log records are stored in the default persistent store for the server. If you plan to migrate clustered servers in the event of a failure, you must set up the default persistent store so that it stores records in a shared storage system that is accessible to any potential machine to which a failed migratable server might be migrated. For highest reliability, use a shared storage solution that is itself highly available—for example, a storage area network (SAN).

For information about server migration, see Whole Server Migration in Administering Clusters for Oracle WebLogic Server.

For more information about setting default persistent store options, see:

Automatic Transaction Recovery Service Migration

You can specify to have the Transaction Recovery Service automatically migrated from an unhealthy server instance to a healthy server instance, with the help of the server health monitoring services. This way the backup server can complete transaction work for the failed server. See Roadmap for Configuring Automatic Migration of the JTA Transaction Recovery Service in Administering Clusters for Oracle WebLogic Server.

Manual Transaction Recovery Service Migration

When a clustered server crashes, you can manually migrate the Transaction Recovery Service from the crashed server to another server in the same cluster using the WebLogic Server Administration Console or the command-line interface. For instructions to manually migrate the Transaction Recovery Service using the WebLogic Server Administration Console, see Manually migrate the Transaction Recovery Service in the Oracle WebLogic Server Administration Console Online Help.

You can also configure WebLogic Server to automatically migrate the Transaction Recovery Service to a healthy candidate server based with the help of WebLogic Server health monitoring of singleton services. See Automatic Transaction Recovery Service Migration.

What Occurs During Transaction Recovery Service Migration

When manual or automatic service migration takes place, the following events occur:

  1. The Transaction Recovery Service on the backup server takes ownership of the transaction log from the crashed server.

  2. The Transaction Recovery Service searches all transaction log records from the failed server for incomplete transactions and completes them as described in Transaction Recovery Service Actions After a Crash.

  3. If the Transaction Recovery Service on the backup server successfully completes all incomplete transactions from the failed server, the server releases ownership of the Transaction Recovery Service for the failed server so the failed server can reclaim it upon restart.

A server can perform transaction recovery for multiple failed servers. While recovering transactions for other servers, the backup server continues to process and recover its own transactions. If the backup server fails during recovery, you can migrate the Transaction Recovery Service to yet another server, which continues the transaction recovery. You can also manually migrate the Transaction Recovery Service back to the original failed server using the WebLogic Server Administration Console or the command-line interface. See Manually Migrating the Transaction Recovery Service to the Original Server.

When a backup server completes transaction recovery for a server, it releases ownership of the Transaction Recovery Service for the failed server. When you restart a failed server, it attempts to reclaim ownership of its Transaction Recovery Service. If a backup server is in the process of recovering transactions when you restart the failed server, the backup server stops recovering transactions, performs some internal cleanup, and releases ownership of the Transaction Recovery service so the failed server can reclaim it and start properly. The failed server then completes its own transaction recovery.

If a backup server still owns the Transaction Recovery Service for a failed server and the backup server is inactive when you attempt to restart the failed server, the failed server does not start because the backup server cannot release ownership of the Transaction Recovery Service. This is also true if the fail back mechanism fails or if the backup server cannot communicate with the Administration Server. You can manually migrate the Transaction Recovery using the WebLogic Server Administration Console or the command-line interface.

Managed Server Independence

Prior to WebLogic Server 10.0, when a cluster's primary Managed Server was booted, but was unable to contact the Administration Server (mostly because that Administration Server had not started yet), then the primary Managed Server would automatically go into MSI (managed server independence) mode and continue to boot up using its local configuration information. During a manual migration of the Transaction Recovery Service, this situation posed a potential risk that a backup server was still recovering TLog data on behalf of the primary Managed Server, which could then lead to concurrent access to TLog and potential corruption of the TLog.

To avoid risking potential TLog corruption, there is a strictOwnershipCheck property on the JTAMigratableTargetMBean. This way, when a primary Managed Server attempts to boot up and it finds that it cannot connect to the Administration Server (for the manual JTA migration policy) or the Singleton Master (for the automatic JTA migration policy), then it verifies its independence by checking the value of the strictOwnershipCheck, as follows:

  • True – This is the recommended setting. The primary Managed Server throws an exception and fail to boot.

  • False – The primary Managed Server skips the Transaction Recovery Service failback, then it can boot successfully. This poses the same TLog corruption risk as in WebLogic Server 9.2 or earlier.

Limitations of Migrating the Transaction Recovery Service

When manually or automatically migrating the Transaction Recovery Service, the following limitations apply:

  • You cannot migrate the Transaction Recovery Service to a backup server from a server that is running. You must stop the server before migrating the Transactions Recovery Service.

  • The backup server does not accept new transaction work for the failed server. It only processes incomplete transactions.

  • The backup server does not process heuristic log files.

  • The backup server only processes log records written by WebLogic Server. It does not process log records written by gateway implementations, including WebLogic Tuxedo Connector.

In addition to the limitations described above, the following rules also apply when WebLogic Server 10.0 or later is configured to automatically migrate the Transaction Recovery Service:

  • If the cluster also contains servers from earlier releases of WebLogic Server, the primary server and backup servers must be WebLogic Server 10.0 or later. To enforce this when automatic migration is enabled, on the WebLogic Server Administration Console, only WebLogic Server 10.0 or later servers appear in the Candidate Servers Available list.

  • Manual service migration is supported between release 9.2 or earlier servers and release 10.0 or later servers if no migration scripts are used.

Preparing to Migrate the Transaction Recovery Service

To migrate the Transaction Recovery Service from a failed server in a cluster to another server (backup server) in the same cluster, the backup server must have access to the transaction log records from the failed server. Therefore, you must store default persistent store data files on persistent storage available to all potential backup servers in the cluster. Consider the following:

  • A storage area network (SAN) is recommended.

  • If you use an NFS file system, configure the NFS server so that disk writes are not cached.

  • Regardless of the storage solution, test failover and migration.

    With some storage solutions, particularly some versions of NFS, file locking can be an issue. You may need to configure your storage server to handle file locks effectively or you may need to turn off file locking for the WebLogic file store.

    Note:

    NFS storage may not fully protect transactional data, as it may be configured to silently buffer synchronous write requests in volatile memory. If a file store Directory is located on an NFS mount, and the file store's Synchronous Write Policy is anything other than Disabled, check your NFS implementation and configuration to make sure that it is configured to support synchronous writes. A Disabled synchronous write policy does not perform synchronous writes, but, as a consequence, is generally not transactionally safe. You may detect undesirable buffering of synchronous write requests by observing high persistent message or transaction throughput that exceeds the physical capabilities of your storage device. On the NFS server, check the synchronous write setting of the exported NFS directory hosting your File Store. A SAN based file store, or a JDBC store, may provide an easier solution for safe centralized storage. See File Locking and NFS in Tuning Performance of Oracle WebLogic Server.

The following persistent store rules apply when manually or automatically migrating the Transaction Recovery Service:

  • The default persistent store cannot be shared by JTA and other migratable services. Other migratable services, such as JMS services, must use another custom store if they are targeted to a migratable target.

  • If post-deactivation and pre-activation scripts are specified to perform any dismounting and mounting of the default store, then the Node Manager must be configure and running on all candidate machines.

The Administration Server must be available when the primary server starts up, fails over, or fails back. This is required to guarantee that the Transaction Recovery Service gets exclusive ownership to its TLog correctly and without conflict. When the primary server starts up, the Transaction Recovery Service connects to Administration Server to get the latest information about JTA. And should failover/failback occur, the Transaction Recovery Service saves the latest information to Administration Server.

When migrating the Transaction Recovery Service from a server, you must stop the failing or failed server before actually migrating the Transaction Recovery Service. If the original server is still running, you cannot migrate the Transaction Recovery Service from it.

All servers that participate in the migration must have a listen address specified in their configuration. See Configure listen addresses in the Oracle WebLogic Server Administration Console Online Help.

Constraining Servers to Which the Transaction Recovery Service Can Migrate

You may want to limit the choices of the servers to use as a Transaction Recovery Service backup for a server in a cluster. For example, all servers in your cluster may not have access to the transaction log records for a server. You can limit the list of destination servers available on the Servers: Configuration: Migration page in the WebLogic Server Administration Console. See Configure candidate servers for Transaction Recovery Service migration in the Oracle WebLogic Server Administration Console Online Help for instructions.

Note:

You must include the original server in the list of chosen servers so that you can manually migrate the Transaction Recovery Service back to the original server, if need be. The WebLogic Server Administration Console enforces this rule.

Viewing Current Owner of the Transaction Recovery Service

When you migrate the Transaction Recovery Service to another server in the cluster, the backup server takes ownership of the Transaction Recovery Service until it completes all incomplete transactions. After which, it releases ownership of the Transaction Recovery Service and the original server can reclaim it. You can see the current owner on the Servers: Control: Migration page in the Oracle WebLogic Server Administration Console Online Help. Follow these instructions:

  1. In the Domain Structure tree in the WebLogic Server Administration Console, expand Environment and click Servers.
  2. Select the original server from which the Transaction Recovery Service was migrated, then select the Control > Migration tab.
  3. Click Advanced. Under JTA Migration Options, Hosting Server indicates the current owner of the Transaction Recovery Service.
Manually Migrating the Transaction Recovery Service to the Original Server

After completing transaction recovery for a failed server, a backup server releases ownership of the Transaction Recovery Service so that the original server can reclaim it when the server is restarted. If the backup server stops (crashes) for any reason before it completes transaction recovery, the original server cannot reclaim ownership of the Transaction Recovery Service and does not start.

You can manually migrate the Transaction Recovery Service back to the original server by selecting the original server as the destination server. The backup server must not be running when you migrate the service back to the original server. Follow the instructions below.

Note:

Please note the following:

  • If a backup server fails before completing the transaction recovery actions, the primary server cannot reclaim ownership of the Transaction Recovery Service and recovery is not re-attempted after the rebooting server. Therefore, you must attempt to manually re-migrate the Transaction Recovery Service to another backup server.

  • If you restart the original server while the backup server is recovering transactions, the backup server gracefully releases ownership of the Transaction Recovery Service. You do not need to stop the backup server. See Recovering Transactions For a Failed Clustered Server.

For instructions on manually migrating the Transaction Recovery Service using the WebLogic Server Administration Console, see Manually migrate the Transaction Recovery Service in the Oracle WebLogic Server Administration Console Online Help.

How to Remove Transaction Records

Before deleting TLogs the WebLogic Server instance should be shutdown gracefully to allow the completion of as many transactions as possible.

Note:

You should delete TLogs only in an extreme case. Deleting the TLogs removes transaction records, resulting in heuristic failures. For example, see Moving a Server.

The location of TLogs is dependent whether you are using the default store, a JDBC TLog store, and if LLR is a participating resource in a transaction.

How to Remove the TLog in the LLR Database

Default name of the LLR table is WL_LLR_SERVERNAME, where SERVERNAME is the name of the server instance. See JDBC LLR Table Name in "Servers: Configuration: General" in Oracle WebLogic Server Administration Console Online Help. To delete the LLR TLog that is kept in the database, remove all the records from the table by issuing drop table WL_LLR_SERVERNAME.

How to Remove the TLog Files from the Default Store

To remove the TLogs in a the default store, delete all files having the following pattern:

$DOMAIN_HOME/servers/servername/data/store/default/_WLS_SERVERNAMExxxxxx.DAT

where xxxxxx are integers ranging from 0 to 9.

Note:

If the default store contains a configured JMS file store, deleting the TLog also deletes the JMS File Store. In this case, before deleting the TLog files, first export the JMS messages to another location. You can then safely delete the TLog files and import the JMS messages back to the original store. See Managing JMS Messages in Administering JMS Resources for Oracle WebLogic Server.

How to Remove the TLog from a JDBC TLog Store

The name of the JDBC TLog store is the PrefixName prepended to the name of the server hosting the JDBC TLog store and ends in "_". For example, a valid JDBC TLog store name using the default Prefix Name is TLOG_MyServer_ where TLOG_ is the Prefix Name and MyServer is the name of the server hosting the JDBC TLog store. You database administrator can remove the existing TLog information from your JDBC TLog store.