PK29964: WTRN0075W AND WTRN0076W OCCUR INDICATING THAT THE TRANLOGS ARE FULL DUE TO CONNECTIONS BEING DESTROYED AND RECREATED. | |||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() APAR status Closed as program error. Error description WTRN0075W/WTRN0076W The transaction log file is full. Transaction rolled back and encountered an exception during the transaction logfile write operation. Example: exception stack trace follows: com.ibm.ejs.jts.tranLog.tranLogFullException: The transaction log file is full after checkpointing. Transaction rolled back. at com.ibm.ejs.jts.tranLog.tranLogMirrored.save (tranLogMirrored.java(Compiled Code)) at com.ibm.ejs.jts.tranLog.tranLogSimple.write (tranLogSimple.java(Compiled Code)) at com.ibm.ejs.jts.tranLog.tranLogTran.logResourceRecord (tranLogTran.java(Compiled Code)) at com.ibm.ejs.jts.jta.recovery.XARecoveryData. logRecoveryEntry(XARecoveryData.java(Compiled Code)) . The following java stack trace may also be logged when this problem occurs This is a stack back trace ■5/19/06 10:01:04:191 JST 4d680a22 tranLogMirror W WTRN0076W: Encountered exception during transaction logfile write operation. The exception stack trace follows: com.ibm.ejs.jts.tranLog.tranLogFullException: The transaction log file is full after checkpointing. Transaction rolled back. at com.ibm.ejs.jts.tranLog.tranLogMirrored.save at com.ibm.ejs.jts.tranLog.tranLogSimple.write at com.ibm.ejs.jts.tranLog.tranLogTran.logResourceRecord at com.ibm.ejs.jts.jta.recovery.XARecoveryData.logRecoveryEntry at com.ibm.ejs.jts.jta.portable.JTAXAResourceImpl.prepare at com.ibm.ejs.jts.jts.ResourceVector.deliverPrepare at com.ibm.ejs.jts.jts.ResourceVector.beforePrepare at com.ibm.ejs.jts.tran.EventCallback.executeCallback at com.ibm.ejs.jts.tran.EventCallback.executeCallbackTree at com.ibm.ejs.jts.tran.EventCallback.executeCallbackTree at com.ibm.ejs.jts.tran.EventPrepare.ExecuteBeforePrepareCallbacks at com.ibm.ejs.jts.tran.EventPrepare.event_LocalPrepareWork at com.ibm.ejs.jts.tran.EventPrepare.event_BecomeCoordinator at com.ibm.ejs.jts.tran.EventControl.event_EndTopLevel at com.ibm.ejs.jts.tran.TrecInterface.end at com.ibm.ejs.jts.jts.TerminatorImpl.commit at com.ibm.ejs.jts.jts.CurrentImpl.commit at com.ibm.ejs.jts.jts.CurrentSet.commit at com.ibm.ejs.jts.jta.UserTransactionImpl.commit at com.ibm.itim.transaction.UserTransactionManager.commit . This problem seems to be due to connection timeouts that are short. The connection in the connection pool is reused, but the corresponding XAResourceInfo that is stored in the tranlog is not found to be equal, so a new one is created. . The following may contribute to the growth of the tranlog files, 1) Every unique JMS connection results in an entry in the XAResource log. These entries remain in the tranlog until the application server is restarted. . 2) The APAR fix PQ90843 does reduce the number of entries in the XAResource log, which is part of the information stored in the tranlog file. . 3) The transaction logs are held in memory while application server is running - disk writes are only forced when updates are made. . To diagnose the problem, the following trace string can be used to trace, com.ibm.ejs.jts.jta.recovery.XARecoveryData=all=enabled:com.ibm. ejs.jts. tranLog.tranLogTran=all=enabled . See if there are findPartnerEntry events that are not finding a matching XAResourceInfo entry.Local fix The J2C code was changed so that when connections are recreated or reused they will match there exisiting entries in the tran log. And a new entry will not be logged. This code fix is only available in an ifix and is only required in 502, Please search the published ifix using this apar number to obtain the fix for this problemProblem summary **************************************************************** * USERS AFFECTED: Users of Websphere Application Server * * version 5.0.2 only. * **************************************************************** * PROBLEM DESCRIPTION: WTRN0075W and WTRN0076W occur * * indicating that the tranlogs are * * full due to connections being * * destroyed and recreated. * **************************************************************** * RECOMMENDATION: * **************************************************************** This problem is due to connection timeouts that are short. The connection in the connection pool is reused, but the corresponding XAResourceInfo that is stored in the tranlog is not found to be equal, so a new one is created.Problem conclusion The J2C code was changed so that when connections are recreated or reused they will match there exisiting entries in the tran log. And a new entry will not be logged. This code fix is only available in an ifix and is only required in version 5.0.2.Temporary fix Comments
APAR is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: Modules/Macros
Publications Referenced
|
Product categories: Software > Application Servers >
Distributed Application & Web Servers > WebSphere Application
Server > General
Operating system(s):
Software version: 00A
Software edition:
Reference #: PK29964
IBM Group: Software Group
Modified date: Aug 23, 2006
(C) Copyright IBM Corporation 2000, 2008. All Rights Reserved.