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.
Related Posts
- WebSphere Application Server: -recovery flag
- WAS: Resolution to Messages in the SIB locked forever
- WebSphere Process Server Endurance
- SCA, BPEL, Websphere Adapter for JDBC and Transactionality
- BPEL: Beware the use of nested loops in a short running process
You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
June 19th, 2008 at 10:53 am
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
June 19th, 2008 at 1:42 pm
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.
June 19th, 2008 at 2:42 pm
Thanks for the reply. I will make note of the server -recovery.
June 23rd, 2008 at 12:34 pm
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
June 23rd, 2008 at 12:44 pm
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.