Troubleshooting Transactions

15 Troubleshooting Transactions

Learn about the troubleshooting tools and tasks that are used in determining why transactions fail and deciding what actions to take to correct the problem.

Overview
WebLogic Server includes the ability to monitor currently running transactions and ensure that adequate information is captured in the case of heuristic completion. It also provides the ability to monitor performance of database queries, transactional requests, and bean methods.
Troubleshooting Tools
WebLogic Server provides aids like exceptions, transaction identifier, transaction status, and so on for transaction troubleshooting.

Overview

WebLogic Server includes the ability to monitor currently running transactions and ensure that adequate information is captured in the case of heuristic completion. It also provides the ability to monitor performance of database queries, transactional requests, and bean methods.

Parent topic: Troubleshooting Transactions

Troubleshooting Tools

WebLogic Server provides aids like exceptions, transaction identifier, transaction status, and so on for transaction troubleshooting.

This topic has following sections:

Parent topic: Troubleshooting Transactions

Exceptions

WebLogic JTA supports all standard JTA exceptions. For more information about standard JTA exceptions, see the API Javadoc for the following packages:

In addition to the standard JTA exceptions, WebLogic Server provides the class weblogic.transaction.RollbackException. This class extends javax.transaction.RollbackException and preserves the original reason for a rollback. Before rolling a transaction back, or before setting it to rollbackonly, an application can supply a reason for the rollback. All rollbacks triggered inside the transaction service set the reason (for example, timeouts, XA errors, unchecked exceptions in beforeCompletion, or inability to contact the transaction manager). Once set, the reason cannot be overwritten.

When a transaction is logged in Database using TLOG store and SQL query, if it takes more than 30 seconds then the SystemException: Transaction could not be logged, is thrown. To solve this issue, look at database performance and Automatic Workload Repository reports to understand the cause of slow down and accordingly perform database tuning.

Parent topic: Troubleshooting Tools

Transaction Identifier

The Transaction Service assigns a transaction identifier (Xid) to each transaction. This ID can isolate information about a specific transaction in a log file. You can retrieve the transaction identifier using the getXID method in the weblogic.transaction.Transaction interface. For detailed information on methods for getting the transaction identifier, see weblogic.transaction.Transaction in the Java API Reference for Oracle WebLogic Server.

Parent topic: Troubleshooting Tools

Transaction Name and Properties

WebLogic JTA provides extensions to javax.transaction.Transaction that support transaction naming and user-defined properties. These extensions are included in the weblogic.transaction.Transaction interface.

The transaction name indicates a type of transaction (for example, funds transfer or ticket purchase) and should not be confused with the transaction ID, which identifies a unique transaction on a server. The transaction name makes it easier to identify a transaction type in the context of an exception or a log file.

User-defined properties are key/value pairs, where the key is a string identifying the property and the value is the current value assigned to the property. Transaction property values must be objects that implement the Serializable interface. You manage properties in your application using the set and get methods defined in the weblogic.transaction.Transaction interface. Once set, properties stay with a transaction during its entire lifetime and are passed between machines as the transaction travels through the system. Properties are saved in the transaction log, and are restored during crash recovery processing. If a transaction property is set more than once, the latest value is retained.

For detailed information on methods for setting and getting the transaction name and transaction properties, see weblogic.transaction.Transaction in the Java API Reference for Oracle WebLogic Server.

Parent topic: Troubleshooting Tools

Transaction Status

The Java Transaction API provides transaction status codes using the javax.transaction.Status class. Use the getStatusAsString method in weblogic.transaction.Transaction to return the status of the transaction as a string. The string contains the major state as specified in javax.transaction.Status with an additional minor state (such as logging or pre-preparing).

Parent topic: Troubleshooting Tools

Transaction Statistics

Transaction statistics are provided for all transactions handled by the transaction manager on a server. These statistics include the number of total transactions, transactions with a specific outcome (such as committed, rolled back, or heuristic completion), rolled back transactions by reason, and the total time that transactions were active. For detailed information about transaction statistics, see View Transaction Statistics in the Oracle WebLogic Remote Console Online Help.

Parent topic: Troubleshooting Tools

Transaction Monitoring

The Remote Console enables you to monitor transactions. Monitoring tasks are performed at the server level. Transaction statistics are displayed for a specific server.

Parent topic: Troubleshooting Tools

Debugging JTA Resources

Once you have narrowed the problem down to a specific application, you can activate WebLogic Server's debugging features to track down the specific problem within the application.

Parent topic: Troubleshooting Tools

Enabling Debugging

You can enable debugging by setting the appropriate ServerDebug configuration attribute to "true." Optionally, you can also set the server StdoutSeverity to "Debug".

You can modify the configuration attribute in any of the following ways.

Parent topic: Debugging JTA Resources

Enable Debugging Using the Command Line

Set the appropriate properties on the command line. For example,

-Dweblogic.debug.DebugJDBCJTA=true 
-Dweblogic.log.StdoutSeverity="Debug"

This method is static and can only be used at server startup.

Parent topic: Debugging JTA Resources

Enable Debugging Using the WebLogic Remote Console

Use the WebLogic Remote Console to set the debugging values:

Log into WebLogic Remote Console and navigate to Edit Tree.
In the left pane, expand Environment and select Servers.
Click the server which you want to enable or disable debugging to view the settings page for that server.
Click the Debug tab.
Select the check box for the debug attributes you want to modify.
Click Save.
Click the Shopping Cart icon and select Commit Changes.

Parent topic: Debugging JTA Resources

Enable Debugging Using the WebLogic Scripting Tool

Use the WebLogic Scripting Tool (WLST) to set the debugging values. For example, the following command runs a program for setting debugging values called debug.py:

java weblogic.WLST debug.py

The debug.py program contains the following code:

user='user1'
password='password'
url='t3://localhost:7001'
connect(user, password, url)
edit()
cd('Servers/myserver/ServerDebug/myserver')
startEdit()
set('DebugJDBCJTA','true')
save()
activate()

Note that you can also use WLST from Java. The following example shows a Java file used to set debugging values:

import weblogic.management.scripting.utils.WLSTInterpreter;
import java.io.*;
import weblogic.jndi.Environment;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;

public class test {
       public static void main(String args[]) {
       try {
              WLSTInterpreter interpreter = null;
              String user="user1";
              String pass="pw12ab";
              String url ="t3://localhost:7001";
              Environment env = new Environment();
              env.setProviderUrl(url);
              env.setSecurityPrincipal(user);
              env.setSecurityCredentials(pass);
              Context ctx = env.getInitialContext();

              interpreter = new WLSTInterpreter();
              interpreter.exec
                     ("connect('"+user+"','"+pass+"','"+url+"')");
              interpreter.exec("edit()");
              interpreter.exec("startEdit()");
              interpreter.exec
                     ("cd('Servers/myserver/ServerDebug/myserver')");
              interpreter.exec("set('DebugJDBCJTA','true')");
              interpreter.exec("save()");
              interpreter.exec("activate()");

       } catch (Exception e) {
       System.out.println("Exception "+e);
       }
       }
}

Using the WLST is a dynamic method and can enable debugging while the server is running.

Parent topic: Debugging JTA Resources

Changes to the config.xml File

Changes in debugging characteristics, through the WebLogic Remote Console, or WLST, or command line are persisted in the config.xml file. See Example 15-1:

Example 15-1 Example Debugging Stanza for JTA

.
.
.
<server>
<name>myserver</name>
<server-debug>
<debug-scope>
<name>weblogic.transaction</name>
<enabled>true</enabled>
</debug-scope>
<debug-jdbcjta>true</debug-jdbcjta>
</server-debug>
</server> 
.
.
.

This sample config.xml fragment shows a transaction debug scope (set of debug attributes) and a single JTA attribute.

Parent topic: Debugging JTA Resources

JTA Debugging Scopes

It is possible to see the tree view of the DebugScope definitions using java weblogic.diagnostics.debug.DebugScopeViewer.

You can enable the following registered debugging scopes for JTA:

DebugJDBCJTA (scope weblogic.jdbc.transaction) - not currently used.
DebugJTAXA (scope weblogic.transaction.xa) - traces for XA resources.
DebugJTANonXA (scope weblogic.transaction.nonxa) - traces for non-XA resources.
DebugJTAXAStackTrace (scope weblogic.transaction.stacktrace) - detailed tracing that prints stack traces at various critical locations.
DebugJTARMI (scope weblogic.transaction.rmi) - not currently used.
DebugJTA2PC (scope weblogic.transaction.twopc) - traces all two-phase commit operations.
DebugJTA2PCStackTrace (scope weblogic.transaction.twopcstacktrace) - detailed two-phase commit tracing that prints stack traces.
DebugJTATLOG (scope weblogic.transaction.tlog) - traces transaction logging information.
DebugJTAJDBC (scope weblogic.transaction.jdbc, weblogic.jdbc.transaction) - traces information about reading/writing JTA records.
DebugJTARecovery (scope weblogic.transaction.recovery) - traces recovery information.
DebugJTAGateway (scope weblogic.transaction.gateway) - traces information about imported transactions.
DebugJTAGatewayStackTrace (scope weblogic.transaction.gatewaystacktrace) - stack traces related to imported transactions.
DebugJTANaming (scope weblogic.transaction.naming) - traces transaction naming information.
DebugJTANamingStackTrace (scope weblogic.transaction.namingstacktrace) - traces transaction naming information.
DebugJTAResourceHealth (scope weblogic.transaction.resourcehealth) - traces information about XA transaction resource health.
DebugJTAMigration (scope weblogic.transaction.migration) - traces information about Transaction Log migration.
DebugJTALifecycle (scope weblogic.transaction.lifecycle) - traces information about the transaction server lifecycle (initialization, suspension, resuming, and shutdown).
DebugJTALLR (scope weblogic.transaction.llr) - traces all Logging Last Resource operations.
DebugJTAHealth (scope weblogic.transaction.health) - traces information about transaction subsystem health.
DebugJTATransactionName (scope weblogic.transaction.name) - traces transaction names.
DebugJTAResourceName (scope weblogic.transaction.resourcename) - traces transaction resource names.

Parent topic: Debugging JTA Resources