Managing Transactions 4-11
4.5.3.7 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
Administration Console. See Configure candidate servers for Transaction Recovery Service migration in the Oracle WebLogic Server Administration Console Help for
instructions.
4.5.3.8 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 Help. Follow these instructions:
1. In the Domain Structure tree in the 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.
4.5.3.9 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: 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 Administration
Console enforces this rule.
4-12 Programming JTA for Oracle WebLogic Server
For instructions on manually migrating the Transaction Recovery Service using the Administration Console, see Manually migrate the Transaction Recovery Service in
the Oracle WebLogic Server Administration Console Help.
4.5.4 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.
The location of TLOGs is dependent on whether LLR is a participaging resource in a transaction.
■
When one resource involved in the transaction is a LLR, then the TLOGs are stored in two locations.
–
The transaction records are stored in a database table. See Section 4.5.4.1,
How to Remove the TLOG in the LLR Database.
–
The server and resource checkpoints are stored in the default store. See Section 4.5.4.2, How to Remove the TLOG Files from the Default Store.
■
If there are no participating LLR in the transactions, the transaction records, server checkpoints, and resource checkpoints are all saved to the TLOG file in the
default store. See Section 4.5.4.2, How to Remove the TLOG Files from the Default
Store.
4.5.4.1 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 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
.
Notes: 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
Section 4.5.3, Recovering Transactions For a Failed Clustered Server
.
Note:
You should delete TLOGs only in an extreme case. Deleting the TLOGs removes transaction records, resulting in heuristic failures.
For example, see Section 4.3, Moving a Server.
