Tuesday, 21 May 2013

Transaction and Partnerlog recovery issues in WebSphere Process Server

Hi all,

After an abnormal server termination or a database outage, WebSphere Application Server might not start correctly or logs exceptions occurs at that time we came across the scenario of transaction logs. For this issue we normally clear the transaction log and restart the services. But deleting transaction logs in production environments causes some problems.

Here are we going to discuss some basic information about the transaction logs. And what to do when WebSphere Process Server does not start (completely) due to Transaction- and Partnerlog recovery issues

Introduction:

WebSphere Process Server uses the transaction log and partner log files of the underlying WebSphere Process Server installation. The application server acts as the transaction manager and the following log files are used:

<profileName>/tranlog/.../transaction

The tranlog directory contains all of the files that hold record details of transactions that are managed by WebSphere Process Server, in particular the current transition state. The transaction service writes information to the transaction log for every global transaction that involves two or more resources, or that is distributed across multiple servers. The partnerlog directory contains files that hold information on resources that are involved in a transaction. The partnerlog directory is important in a recovery scenario to allow WebSphere Application Server to re-create a resource for recovery after the server is recycled.

When a global transaction is completed, the information in the transaction log is no longer required, and the information is marked for deletion. The redundant information is garbage collected and intervals, and the space is reused by new transactions. The log files are created with a fixed size at server startup, so no further disk space allocation is required during the lifetime of the server.

If all the log space is in use when a transaction needs to save information, the transaction is rolled back and the message 'CWWTR0083W: The transaction log is full.' Transaction rolled back. is reported to the system error log. No more transactions can commit until more log space is made available when existing active transactions complete.

Effects of deleting the transaction or partner log:

Deleting the transaction or partner log file from a WebSphere Process Server environment can cause inconsistencies in active Business Process Execution Language (BPEL) processes or resource adapters that participate in a transaction. If you delete the log files, the processes might not progress or might not complete an outstanding transaction. Also, recovery mechanisms do not work for WebSphere Process Server-related components. Finally, process navigation information remains in the business process engine (BPE) database, and navigation messages remain in the corresponding destinations; the data and messages are not processed.

Do not delete the transaction or partner log file from a production environment.

Without these files, there is no WebSphere Process Server functionality to recover transactional information. In addition, long-running processes remain in an inconsistent state and you cannot complete the process flow except by deleting running instances. This approach might cause you to lose operational or business-critical data, which makes the database inconsistent with the message destination. Other inconsistencies that might be caused by deleting the files are:
  • Started transactions will neither be rolled back nor committed.
  • Artifacts will remain in the Java™ virtual machine (JVM) because they are referenced or allocated by a transaction but never garbage collected.
  • Database content (amongst others navigation state of long running BPEL processes) remains in the Business Process Choreographer related tables and are never deleted.
  • Navigation messages of the Business Process Engine (BPE) of long running processes are never processed further.
  • Service Component Architecture (SCA) messages that belong to a process navigation and transaction remain on SCA-related queues.

Therefore Deleting the transaction log might lead to an inconsistency in your production database. We are not able to recover from this situation. The following document contains more information on the contents of transaction- and partner logs and the effect deleting them can have on your environment:

Complete the following steps to recover in doubt transactions:

1.Start all servers ( in a clustered environment) in recovery mode, using the following command:

profileRoot/bin/startServer.(bat|sh) serverName -recovery

This command using the recovery option causes the server to start and perform only transaction recovery before shutting the server down again.

2.Start the application servers again.

3.Check, using the administrative console, if there are any in doubt transaction left. Navigate to:

Servers > Application Servers > serverName > Container Services > Transaction service > Runtime tab

If remaining in-doubt transactions are listed, select all of them and initiate a rollback.

may this will work fine for you


Effort only fully releases its reward after a person refuses to quit.”

Regards,
Akhilesh B. Humbe

1 comment:

  1. Once in a while we need to confront a great deal of perplexity when we discovered diverse assessment of various several articles identified with same question. In any case, I think now I am near resolve my questions subsequent to perusing this blog. comprare nocciole online

    ReplyDelete

Popular Posts