BEA Logo BEA WebLogic Server Release 6.1

  BEA Home  |  Events  |  Solutions  |  Partners  |  Products  |  Services  |  Download  |  Developer Center  |  WebSUPPORT



  WebLogic Server Doc Home   |     Administration Guide   |   Previous Topic   |   Next Topic   |   Contents   |   Index   |   View as PDF

Managing Transactions


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 and enabling the WebLogic Server features, including the JavaTransaction API (JTA). To invoke the Administration Console, see the procedures provided in Configuring WebLogic Servers and Clusters. The transaction configuration process involves specifying values for attributes. These attributes define various aspects of the transaction environment:

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.


Configuring Transactions

The Administration Console provides default values for all JTA configuration attributes. If you specify an invalid value for any configuration attribute, the WebLogic Server does not boot when you restart it.

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.

Once you configure WebLogic JTA and any transaction participants, the system can perform transactions using the JTA API and the WebLogic JTA extensions.

You can configure any transaction attributes before running applications (static configuration) or, with one exception, at application run time (dynamic configuration). The TransactionLogFilePrefix attribute must be set before running applications.

To configure transaction attributes, do the following:

  1. Start the Administration Console.

  2. Select the domain node in the left pane. The Configuration tab for the domain is displayed by default.

  3. Select the JTA tab.

  4. For each attribute, specify a value or, if available, accept the default value.

  5. Click Apply to store new attribute values.

  6. Ensure that the Transaction Log File Prefix attribute is set when you configure the server. For more information on setting the logging attribute, see Monitoring and Logging Transactions.

Table  15-1 briefly describes the transaction attributes available with WebLogic Server. For detailed information about attributes, and valid and default values for them, see the Domain topic in the Administration Console Online Help.

Table 15-1 Transaction Attributes



Timeout Seconds

Time, in seconds, a transaction may be active before the system forces a rollback.

Abandon Timeout Seconds

Maximum time, in seconds, that a transaction coordinator persists in attempting to complete a transaction.

Before Completion Iteration Limit

Number of beforeCompletion callbacks that are processed before the system forces a rollback.

Max Transactions

Maximum number of transactions that may be active on a particular server at one time.

Max Unique Name Statistics

Maximum number of unique transaction names that may be tracked by a server at one time.

Forget Heuristics

Boolean value specifying whether the transaction manager should instruct a resource to forget any transaction with a heuristic outcome.


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  15-2:

Table 15-2 XA Resource Health Monitoring Configuration Attributes





Enables or disables resource health monitoring for the JDBC connection pool. This attribute only applies to connection pools that use an XA JDBC driver for database connections. It is ignored if a non-XA JDBC driver is used.

If set to true, resource health monitoring is enabled. If an XA resource fails to respond to an XA call within the period specified in the MaxXACallMillis attribute, WebLogic Server marks the connection pool as unhealthy and blocks any further calls to the resource.

If set to false, the feature is disabled.

Default: true


Sets the maximum allowed duration (in milliseconds) of XA calls to XA resources. This setting applies to the entire domain.

Default: 120000


The maximum duration (in milliseconds) that an XA resource is marked as unhealthy. After this duration, the XA resource is declared available again, even if the resource is not explicitly re-registered with the transaction manager. This setting applies to the entire domain.

Default: 1800000


Maximum number of concurrent requests to resources allowed for each server in the domain.

Default: 50

Minimum: 10

Maximum: java.lang.Integer.MAX_VALUE


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:




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:

  1. Start the Administration Console.

  2. Click the server node in the left pane.

  3. Select a specific server in the left pane.

  4. Select the Monitoring tab.

  5. Select the JTA tab. Totals for transaction statistics are displayed in the JTA dialog. (You can also click the monitoring text links to monitor transactions by resource or by name, or to monitor all active transactions.)

  6. Select the Logging tab.

  7. Select the JTA tab.

  8. Enter a transaction log file prefix then click Apply to save the attribute setting.

For detailed information on monitoring and logging values and attributes, see the Server topic in the Administration Console Online Help.


Moving a Server to Another Machine

When an applications server is moved to another machine, it must be able to locate the transaction log files on the new disk. For this reason, we recommend moving the transaction log files to the new machine before starting the server there. By doing so, you can ensure that recovery runs properly. If the pathname is different on the new machine, update the TransactionLogFilePrefix attribute with the new path before starting the server.

When migrating 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.


back to top previous page next page