PK29964: WTRN0075W AND WTRN0076W OCCUR INDICATING THAT THE TRANLOGS ARE FULL DUE TO CONNECTIONS BEING DESTROYED AND RECREATED.

 A fix is available

PK29964; 5.0.2.18: wtrn0075w and wtrn0076w occur indicating tranlogs are full



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 problem
Problem 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 information
APAR number PK29964
Reported component name WEBSPHERE BASE
Reported component ID 5630A3600
Reported release 00A
Status CLOSED PER
PE NoPE
HIPER NoHIPER
Special Attention NoSpecatt
Submitted date 2006-08-16
Closed date 2006-08-23
Last modified date 2006-08-23

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Modules/Macros
J2C          

Publications Referenced

Fix information
Fixed component name WEBSPHERE BASE
Fixed component ID 5630A3600

Applicable component levels
R003 PSY    UP
R00A PSY    UP
R00H PSY    UP
R00I PSY    UP
R00P PSY    UP
R00S PSY    UP
R00W PSY    UP


Document Information


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