bea.com | products | dev2dev | support | askBEA |
![]() |
![]() |
|
![]() |
e-docs > WebLogic Server > Administration Console Online Help > JTA |
Administration Console Online Help
|
On the Domain
Configuration settings for JTA (transactions) are applicable at the domain level. This means that configuration attribute settings apply to all servers within a domain. Monitoring and logging tasks for JTA are performed at the server level.
You can configure any transaction attributes before starting the server (static configuration) or, with one exception, while the server is running (dynamic configuration). The TransactionLogFilePrefix attribute must be set before starting the server.
Configuring Domains for Inter-Domain Transactions
For a transaction manager to manage distributed transactions, the transaction manager must be able to communicate with all participating servers to prepare and then commit or rollback the transactions. This applies to cases when your WebLogic domain acts as the transaction manager or a transaction participant (resource) in a distributed transaction. The following sections describe how to configure your domain to enable inter-domain transactions. To learn more about interoperability between WebLogic domains, see Enabling Trust Between WebLogic Domains.
Limitations for Inter-Domain Transactions
Please note the following limitations for inter-domain transactions:
Inter-Domain Transactions for WebLogic Server 8.x and 7.x Domains
To manage or participate in transactions that span multiple WebLogic Server 8.x and 7.x domains (that is, all participating domains run on WebLogic Server 7.x or 8.x, or a combination of 7.x and 8.x), you must set a security credential for all domains to the same value. To set the credential value, follow these steps for each participating domain:
Inter-Domain Transactions Between WebLogic Server 7.x/8.x and WebLogic Server 6.x Domains
To manage transactions that use servers in both WebLogic Server 7.x or 8.x and WebLogic Server 6.x domains, you must do the following:
In all participating WebLogic Server 6.x domains:
In all participating WebLogic Server 7.x and 8.x domains:
In the Administration Console, you can monitor transactions for each server in the domain. Transaction statistics are displayed for a specific server, not the entire domain, even though transaction settings apply to the entire domain.
Viewing Transaction Statistics for a Server
To view transaction statistics for a server, follow these steps:
Viewing Transaction Statistics for Named Transactions
To view aggregate statistics about named transactions coordinated by a server, follow these steps:
Viewing Transaction Statistics for Server Resources
To view aggregate statistics for each transactional resource accessed on a server, follow these steps:
Viewing Current (Inflight) Transactions for a Server
To view aggregate statistics for each transactional resource accessed on a server, follow these steps:
Manually Resolving Current (Inflight) Transactions
In some cases, a transaction may not complete normally due to system or network failures. In such situations there may be locks held on behalf of the pending transaction that are inhibiting the progress of other 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. You can also manually resolve "stuck" transactions.
To manually resolve a transaction, you view current (inflight) transactions for a server from the Server
Note that 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.
Manual Commit and Rollback Options
To manually resolve a transaction, you can choose from the following options. Options are restricted as described in Table 4-1.
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 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.
To Manually Resolve a Transaction
See Manually Resolving Current (Inflight) Transactions for more information about manually resolving transactions.
Each server has a transaction log which stores information about committed transactions coordinated by the server that may not have been completed. WebLogic Server uses the transaction log when recovering from system crashes or network failures. You cannot directly view the transaction log—the file is in a binary format.
The transaction log consists of multiple files. Each file is subject to garbage collection by the transaction manager. That is, when none of the records in a transaction log file are needed, the system deletes the file and returns the disk space to the file system. In addition, the system creates a new transaction log file if the previous log file becomes too large or a checkpoint occurs.
Caution: Do not manually delete transaction log files. Deleting transaction log files may cause inconsistencies in your data.
Transaction log files are uniquely named using a pathname prefix, the server name, a four-digit numeric suffix, and a file extension. The pathname prefix determines the storage location for the file. You can specify a value for the TransactionLogFilePrefix server attribute using the WebLogic Administration Console. The default TransactionLogFilePrefix is the server's working directory.
You should set the TransactionLogFilePrefix so that transaction log files are created on a highly available file system, for example, on a RAID device. To take advantage of the migration capability of the Transaction Recovery Service for servers in a cluster, you must store the transaction log in a location that is available to a server and its backup servers, preferably on a dual-ported SCSI disk or on a Storage Area Network (SAN). See Preparing to Migrate the Transaction Recovery Service for more information.
On a UNIX system with a server name of websvr and with the TransactionLogFilePrefix set to /usr7/applog1/, you might see the following log files:
/usr7/applog1/websvr0000.tlog
/usr7/applog1/websvr0001.tlog
/usr7/applog1/websvr0002.tlog
Similarly, on a Windows system with the TransactionLogFilePrefix set to C:\weblogic\logA\, you might see the following log files:
C:\weblogic\logA\websvr0000.tlog
C:\weblogic\logA\websvr0001.tlog
C:\weblogic\logA\websvr0002.tlog
If you notice a large number of transaction log files on your system, this may be an indication of multiple long-running transactions that have not completed. This can be caused by resource manager failures or transactions with especially large timeout values.
If the file system containing the transaction log runs out of space or is inaccessible, commit() throws SystemException, and the transaction manager places a message in the system error log. No transactions are committed until more space is available.
When migrating a server to another machine, move the transaction log files as well, keeping all the log files for a server together. See Moving a Server to Another Machine for more information.
Setting the Transaction Log File Location (Prefix)
To set the prefix for the transaction log files, which determines the location of the transaction log files, follow these steps:
When importing transactions from a foreign transaction manager into WebLogic Server, the WebLogic Server transaction manager acts as an XA resource coordinated by the foreign transaction manager. In rare catastrophic situations, such as after the transaction abandon timeout expires or if the XA resources participating in the WebLogic Server imported transaction throw heuristic exceptions, the WebLogic Server transaction manager will make a heuristic decision. That is, the WebLogic Server transaction manager will decide to commit or roll back the transaction without input from the foreign transaction manager. If the WebLogic Server transaction manager makes a heuristic decision, it stores the information of the heuristic decision in the heuristic log files until the foreign transaction manager tells it to forget the transaction.
Heuristic log files are stored with transaction log files and look similar to transaction log files with .heur before the .tlog extension. They use the following format:
<TLOG_file_prefix>\<server_name><4-digit number>.heur.tlog
On a UNIX system with a server name of websvr, you might see the following heuristic log files:
/usr7/applog1/websvr0000.heur.tlog
/usr7/applog1/websvr0001.heur.tlog
/usr7/applog1/websvr0002.heur.tlog
Similarly, on a Windows system, you might see the following heuristic log files:
C:\weblogic\logA\websvr0000.heur.tlog
C:\weblogic\logA\websvr0001.heur.tlog
C:\weblogic\logA\websvr0002.heur.tlog
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:
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 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.
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 will continue to try to complete the transaction until all resource managers indicate that the transaction is completed. Using the AbandonTimeoutSeconds attribute, you can set the maximum time, in seconds, that a transaction manager will persist 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 will roll back the transaction to release any locks held on behalf of the abandoned transaction and will write an heuristic error to the server log.
Moving a Server to Another Machine
When an application server is moved to another machine, it must be able to locate the transaction log files on the new disk. For this reason, BEA recommends moving the transaction log files to the new machine before starting the server on the new machine. By doing so, you can ensure that recovery runs properly. When you start WebLogic Server on the new system, the server reads the transaction log files to recover pending transactions, if any. If the pathname is different on the new machine, update the TransactionLogFilePrefix attribute with the new path before starting the server. For instructions on how to change the TransactionLogFilePrefix, see Setting the Transaction Log File Location (Prefix).
Transaction Recovery After a Server Fails
The WebLogic Server transaction manager is designed to recover from system crashes with minimal user intervention. The transaction manager 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, WebLogic Server provides the Transaction Recovery Service, which automatically attempts to recover transactions on system startup. The Transaction Recovery Service owns the transaction log for a server. On startup, the Transaction Recovery Service parses all log files 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, BEA 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 transaction log files) to another system (machine) to recover transactions. See Recovering Transactions for a Failed Non-Clustered Server for more information. For a server in a cluster, you can manually migrate 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 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 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 Using WebLogic Server Clusters.
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:
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.
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().
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 for more information.
The Transaction Recovery Service provides the following benefits:
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.
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 for more information.
Recovering Transactions for a Failed Non-Clustered Server
To recover transactions for a failed server, follow these steps:
When moving transaction logs after a server failure, make all transaction log files available on the new machine before starting the server there. You can accomplish this by storing transaction log files on a dual-ported disk available to both machines. As in the case of a planned migration, update the TransactionLogFilePrefix attribute with the new path before starting the server if the pathname is different on the new machine. Ensure that all transaction log files are available on the new machine before the server is started 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.
Note: The Transaction Recovery Service is designed to gracefully handle transaction recovery after a crash. BEA 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 crashes, you can manually migrate the Transaction Recovery Service from the crashed server to another server in the same cluster using the Administration Console or the command line interface. The following events occur:
For instructions to migrate the Transaction Recovery Service using the Administration Console, see Migrating the Transaction Recovery Service to a Server in the Same Cluster.
A server can perform transaction recovery for more than one failed server. 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 will continue the transaction recovery. You can also manually migrate the Transaction Recovery Service back to the original failed server using the Administration Console or the command line interface. See Manually Migrating the Transaction Recovery Service Back to the Original Server for more information.
When a backup server completes transaction recovery for a server, it releases ownership of the Transaction Recovery Service (and transaction logs) 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 will then complete 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 will 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 Administration Console or the command line interface.
Limitations of Migrating the Transaction Recovery Service
When migrating the Transaction Recovery Service, the following limitations apply:
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 files from the failed server. Therefore, you must store transaction log files on persistent storage available to both (or more) servers. BEA recommends that you store transaction log files on a Storage Area Network (SAN) device or a dual-ported disk. Do not use an NFS file system to store transaction log files. Because of the caching scheme in NFS, transaction log files on disk may not always be current. Using transaction log files stored on an NFS device for recovery may cause data corruption.
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.
For detailed instructions to migrate the Transaction Recovery Service, see Migrating the Transaction Recovery Service to a Server in the Same Cluster in the Administration Console Online Help.
Migrating the Transaction Recovery Service to a Server in the Same Cluster
To migrate the Transaction Recovery Service from a failed server in a cluster, follow these steps:
Note: The Transaction Recovery Service is designed to gracefully handle transaction recovery after a crash. BEA recommends that you attempt to restart a crashed server and allow the Transaction Recovery Service to handle incomplete transactions, rather than migrate the Transaction Recovery Service to another server.
Constraining the 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 files for a server. You can limit the list of destination servers available on the Server
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.
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 Server
Manually Migrating the Transaction Recovery Service Back 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 will 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:
Overview of Transaction Management
You use the Administration Console to access tools for configuring the WebLogic Server features, including the Java Transaction API (JTA). The transaction configuration process involves specifying values for attributes. These attributes define various aspects of the transaction environment:
Settings you make in the Administration Console, including configuration settings for JTA, are persisted in the config.xml file for the domain. For information about entries in this file, see the following sections of the Configuration Reference Guide:
Before configuring your transaction environment, you should be familiar with the J2EE components that can participate in transactions, such as EJBs, JDBC, and JMS.
![]() |
![]() |
![]() |
![]() |
||
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |