|
 |
| e-docs > WebLogic Server > Administration Guide > Managing Transactions |
|
Administration Guide
|
These sections discuss transaction management and provide guidelines for configuring and managing transactions through the Administration Console.
For information on configuring JDBC connection pools to allow JDBC drivers to participate in distributed transactions, see Managing JDBC Connectivity.
Overview of Transaction Management
You use the Administration Console to access tools for configuring the WebLogic Server features, including the Java Transaction API (JTA). To invoke the Administration Console, see the procedures provided in Starting and Using the Administration Console in the Administration Guide. 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.
For more information about configuring J2EE components, see the applicable sections of this document and the Administration Console Online Help.
Configuration settings for JTA 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.
To modify transaction attributes, do the following:
For detailed information about the transaction attributes available with WebLogic Server, including valid and default values, see the Domain topic in the Administration Console Online Help.
Additional Attributes for Managing Transactions
By default, if an XA resource that is participating in a global transaction fails to respond to an XA call from the WebLogic Server transaction manager, WebLogic Server flags the resource as unhealthy and unavailable, and blocks any further calls to the resource in an effort to preserve resource threads. The failure can be caused by either an unhealthy transaction or an unhealthy resource—there is no distinction between the two causes. In both cases, the resource is marked as unhealthy.
To mitigate this limitation, WebLogic Server provides the configuration attributes listed in Table 7-1:
You set these attributes directly in the config.xml file when the domain is inactive. These attributes are not available in the Administration Console. The following example shows an excerpt of a configuration file with these attributes:
...
<JTA
MaxUniqueNameStatistics="5"
TimeoutSeconds="300"
RecoveryThresholdMillis="150000"
MaxResourceUnavailableMillis="900000"
MaxResourceRequestOnServer="60"
MaxXACallMillis="180000"
/>
<JDBCConnectionPool
Name="XAPool"
Targets="myserver"
DriverName="weblogic.qa.tests.transaction.
testsupport.jdbc.XADataSource"
InitialCapacity="1"
MaxCapacity="10"
CapacityIncrement="2"
RefreshMinutes="5"
TestTableName="dual"
EnableResourceHealthMonitoring="true"
Properties="user=scott;password=tiger;server=dbserver1"
/>
<JDBCTxDataSource
Name="XADataSource"
Targets="myserver"
JNDIName="weblogic.jdbc.XADS"
PoolName="XAPool"
/>
...
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.
Limitations for Inter-Domain Transactions
Please note the following limitations for inter-domain transactions:
Note: BEA recommends that you use an XA driver instead of a non-XA driver (with Emulate Two-Phase Commit) in global transactions. There are risks involved with using a non-XA driver in a global transaction. See Limitations and Risks When Using a Non-XA Driver in Global Transactions in the Administration Guide for more details about the risks.
Inter-Domain Transactions for WebLogic Server Domains
To manage or participate in transactions that span multiple WebLogic Server domains (that is, all participating domains run on WebLogic Server 9.x, 8.x, 7.x, and 6.x domains or a combination of 9.x, 8.x, 7.x and 6.x ), you must enable inter-domain transactions by establishing domain trust and setting the Security Interoperability Mode. For all participating domains:
Using Security Interoperability Mode
Security Interoperability Mode enables you to configure compatible communication channels between servers in global transactions.
Configuring Security Interoperability Mode
To configure Security Interoperability Mode, every participating server must set the following flag to the same value:
-Dweblogic.transaction.SecurityInteropMode=value
The default value of this flag is performance.
Determining the Security Interoperability Mode
Use the following table to determine the Security Interoperability Mode settings required when configuring communication channels for inter-domain transactions.
Note: When Security Interoperability Mode is set to performance, you are not required to set domain trust between the domains.
Monitoring and Logging Transactions
The Administration Console allows you to monitor transactions and to specify the transaction log file prefix. Monitoring and logging tasks are performed at the server level. Transaction statistics are displayed for a specific server and each server has a transaction log file.
To display transaction statistics and to set the prefix for the transaction log files, do the following:
For detailed information on monitoring and logging values and attributes, see the following sections in the Administration Console Online Help:
You can monitor transactions in progress using the WebLogic Console. In addition to displaying statistics, as described in Transaction Statistics in Programming WebLogic JTA, you can display the following:
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. 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 Write Policy
You can select a transaction log file write policy to change the way WebLogic Server writes transaction log file entries. You can select either of the following options:
Warning: On Windows, the Direct-Write transaction log file write policy may leave transaction data in the on-disk cache without immediately writing it to disk. This is not transactionally safe because a power failure can cause loss of on-disk cache data. To prevent cache data loss when using the Direct-Write transaction log file write policy on Windows, disable all write caching for the disk (enabled by default) or use a battery backup for the system.
The transaction log file write policy can affect transaction performance. You should test these options with your system to see which performs better. Direct-Write typically performs as well or better than Cache-Flush, depending on operating system and OS parameter settings, and is available on Windows, HP-UX, and Solaris. Windows systems optimize serial writes to disk such that subsequent writes to a file get faster after the first write to the file. Transaction log file entries are written serially, so this could improve performance. On some UNIX systems, the Cache-Flush option will flush all cached disk writes, not only those for the transaction log file, which could degrade transaction performance.
To set the transaction log file write policy, 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
An 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.
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.
BEA recommends configuring server instances using DNS names rather than IP addresses to promote portability.
Moving a Server to Another Machine
Note: BEA recommends moving the transaction log files to the new machine before starting the server on the new machine. By doing so, you ensure that the transaction recovery process runs properly. When you start WebLogic Server on the new system, the server reads the transaction log files to recover pending transactions, if any.
When an application server is moved to another machine, it must be able to locate the transaction log files on the new disk. 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 Specifying the Transaction Log File Location in the Administration Console Online Help.
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. For more information, see:
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-cluster 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 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 For instructions on how to set the AbandonTimeoutSeconds attribute, see Configuring JTA in the Administration Console Online Help. For more information about the two-phase commit process, see Distributed Transactions and the Two-Phase Commit Protocol in Programming WebLogic JTA." on page 7-19 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 in the Administration Console online help. For instructions to migrate the Transaction Recovery Service using the command line interface, see MIGRATE in WebLogic Server Command-Line Interface Reference.
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 in the Administration Console online help 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.
You can also use the command line to migrate the Transaction Recovery Service. See MIGRATE in WebLogic Server Command-Line Interface Reference.
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
