+

Search Tips   |   Advanced Search

Troubleshooting transactions

Use this overview task to help resolve a problem that you think is related to the Transaction service.

To identify and resolve transaction-related problems, we can use the standard WebSphere Application Server RAS facilities. If we encounter a problem that you think might be related to transactions...

  1. Check for transaction messages in the console.

    The Transaction service produces diagnostic messages prefixed by "CWWTR". The error message indicates the nature of the problem and provides some detail. The associated message information provides an explanation and any user actions to resolve the problem.

  2. Check for Transaction messages.

    Check the activity log.

    (zos) Check the error log.

  3. Check for more messages in additional places.

    Check the application server stdout.log. For more information about a problem, check the stdout.log file for the application server, which should contain more error messages and extra details about the problem.

    (zos) Check for more messages in other potential message output repositories. For more information about a problem, check the standard output file configured by your administrator. This will contain more error messages and other detailed information about the problem.

  4. Check for messages related to the application server transaction log directory when the problem occurred.

    If we changed the transaction log directory and a problem caused the application server to fail (with in-flight transactions) before the server was restarted properly, the server will next start with the new log directory and be unable to automatically resolve in-flight transactions that were recorded in the old log directory. To resolve this, we can copy the transaction logs to the new directory then stop and restart the application server.

  5. (zos) Check the RRS logs for any transaction activity involving RRS-compliant resources. IBM WebSphere Application Server for z/OS is capable of supporting both XA and RRS resource managers, and of coordinating a mix of RRSTransactional resource managers and XA capable resource managers under the same global transaction. If the installation uses XA resource managers, RRS resource managers, or a mixture of both, we can use the console to view transaction logs containing information about all transactions. We can find additional information about RRS transactions using the RRS panels.

  6. Check the hints and tips for troubleshooting transactions.

    See the topic about Transaction troubleshooting tips for an ongoing collection of troubleshooting tips, based on test and user experience. If we have suggestions for other tips, please let the IBM WebSphere writing team know.

  7. (iseries) Change the the SCA composite files to use the noManagedTransaction intent. Global and local transactions for SCA are not supported when you use JDBC to connect to resources, so use noManagedTransaction intents.

    If we use managed local transaction intent or global transaction intent in SCA composites, this will turn off autocommit when you use JDBC on the IBM i platform. If multiple SQL jobs need to lock the same table for an update, the following exception will appear:

      SQLException: com.ibm.db2.jdbc.app.DB2DBException: Row or object WAREHOUSE in CBIVP type *FILE in use

    The first SQL job that locks the table never commits the transaction, and the lock is never released.

    1. In the SCA composite files, change both managedTransaction.local and managedTransaction.global to noManagedTransaction. Change

        requires="managedTransaction.local"

      and

        requires="managedTransaction.global"

      to

        requires="noManagedTransaction"

    2. In the SCA composite files, change propogateTransaction to suspendsTransaction. Change

        requires="propagatesTransaction"

      to

        requires="suspendsTransaction"


Subtopics


Related tasks

  • Configuring transaction properties for an application server

    Managing transaction logging for optimum server availability