Tip: WebSphere Process Server – Do not delete the ‘tranlog’ on a production server

In development mode, one of the steps to ‘clean up’ from a wonky process server instance is to delete the wstemp, temp directories along with the ‘tranlog’. The ‘tranlog’ is an internal file that WebSphere Application Server uses to manage in-flight transactions and attempt to recover them should the server crash. When you delete the tranlog, you remove this information from process server’s memory. At development time, your transactions are transient, you don’t really care if they complete or not, a new one can be created at any time.

On a production server, though, each transaction should be considered an extremely precious resource that can’t be deleted. Therefore, the tip that some of us use to delete the tranlog should NEVER be done on a production server. Removing it may lead to an inconsistency in your production database which may be unrecoverable.

Author: dan

Comments

  1. Dan – Though it is not a good practice to remove transaction logs in Prod, I see it becomes unavoidable sometimes. This happens in cases where by some times the server spews out XA transction recovery exceptions periodically. Can you please give some insight or a link on how to recover these transactions without taking the hard route.
    Thanks
    Phani

  2. Thats a great point.

    I am actually working with IBM resources to bring a server back that crashed and has the standard tranlog issues.

    Basically, it boils down to start the server with -recovery which I described in a later post. This gives the admin the chance to manually roll-back or commit transactions.

    As an aside, we are experiencing issues with Oracle and recovery that I’m waiting for the issue on in order to blog it, but I would say doing the step above resulted in 98% of the transactions being cleared out of the log.

  3. Phani – typically the transaction manager is retrying periodically because it can’t contact the resource manager in question. If you know it is never going to succeed (the database no longer exists for example) then you can review and complete the indoubt transactions on the runtime tab of the transaction service in the administrative console.

    Regards,
    David

  4. Strangely enough, I have a production server with 0 in-doubt transactions that keeps trying to contact an external transaction agent (Oracle) every 5 minutes and fails.

Leave a Reply

Your email address will not be published. Required fields are marked *