13 Troubleshooting Transactions

This chapter describes troubleshooting tools and tasks for use in determining why transactions fail and deciding what actions to take to correct the problem.

This section discusses the following topics:


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 the following aids to transaction troubleshooting:


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.

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.

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.

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).

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 "Monitor JTA" in the Oracle WebLogic Server Administration Console Online Help.

Transaction Monitoring

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

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.

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.

Enable Debugging Using the Command Line

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


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

Enable Debugging Using the WebLogic Server Administration Console

Use the WebLogic Server Administration Console to set the debugging values:

  1. If you have not done so, in the Change Center of the Administration Console, click Lock & Edit (see "Use the Change Center" in Oracle WebLogic Server Administration Console Online Help).

  2. In the left pane of the console, expand Environment and select Servers.

  3. On the Summary of Servers page, click the server on which you want to enable or disable debugging to open the settings page for that server.

  4. Click Debug.

  5. Expand default.

  6. Select the check box for the debug scopes or attributes you want to modify.

  7. Select Enable to enable (or Disable to disable) the debug scopes or attributes you have checked.

  8. To activate these changes, in the Change Center of the Administration Console, click Activate Changes.

  9. Not all changes take effect immediately—some require a restart (see "Use the Change Center" in Oracle WebLogic Server Administration Console Online Help).

    This method is dynamic and can enable debugging while the server is running.

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:

connect(user, password, url)

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();
              Context ctx = env.getInitialContext();

              interpreter = new WLSTInterpreter();

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

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

Changes to the config.xml File

Changes in debugging characteristics, through console, or WLST, or command line are persisted in the config.xml file. See Example 13-1:

Example 13-1 Example Debugging Stanza for JTA


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

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 2-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.