LI77564: CMVC 230894 - Avoid memory leak when TransactionManager is not called to create the current transaction

APAR status

• Closed as program error.

Error description

• OutOfMemory can occur if TransactionManager is not called to
  create transaction.  The OptCounter is not properly cleaned up
  which leads to memory leak.
  

Local fix

• Call TransactionManager to create transaction when updating
  database.
  

Problem summary

• USERS AFFECTED:
   Any customer that is updating database without creating
  transaction via TransactionManager
  
   PROBLEM ABSTRACT:
   Avoid memory leak when TransactionManager is not called to
  create the current transaction
  
   BUSINESS IMPACT:
   OutOfMemory can occur over time
  
   RECOMMENDATION:
  

Problem conclusion

• This iFix helps avoids a possible out of memory condition by
  changing the default behavior for the OptCounterInfo class.  The
   OptCounterInfo class remembers in memory all OPTCOUNTER column
  values used by WebSphere Commerce EJB beans.  The remembered
  information for each thread is cleared from memory when the
  TransactionManager begin, commit, and rollback methods are
  called to begin or end a database transaction.  Previously, the
  number of OPTCOUNTER column values remembered could grow without
   limit.  With this iFix, when the number of OPTCOUNTER column
  values remembered reaches a specified limit, and there is no
  active transaction that was created by the
  TransactionManager.begin method,  they are cleared from memory.
   The default limit is 50,000 per thread.  The previous behavior
  (no limit) can be restored by specifying a limit of -1.
  
   To change the new default behavior, add the following tags to
  the InstanceProperties tag in the wc-server.xml WebSphere
  Commerce instance configuration file (the new default values are
  shown):
         <com.ibm.commerce.base.helpers.OptCounterInfo
           maxNoTransactionActive="50000"
           stackTraceOnMaxNoTransactionActive="false"
         />
   where:
  
   maxNoTransactionActive specifies the threshold number of EJBs
  that can be accessed by a thread while no database transaction
  has been started using the Commerce TransactionManager.begin
  method without clearing the remembered optcounter information
  for those EJBs.
  
   Once this threshold is reached, all optcounter information for
  the thread is removed from memory. The default threshold is
  50,000.  To revert to the previous behavior, specify -1, so that
  all optcounter information is remembered in memory until the
  start of the next transaction.
  
   stackTraceOnMaxNoTransactionActive specifies that a stack trace
  should be written to the SystemErr.log file when the specified
  threshold is reached.  Search for the string "Clearing
  OptCounterInfo due to size" and use this stack trace to help
  find the code that is not using the TransactionManager.begin
  method.
  
   This iFix also causes the optcounter information to be cleared
  when the TransactionManager begin, commit, and rollback methods
  are called while the current database transaction was not
  created using the TransactionManager.begin method.  Custom code
  that executes within such a transaction can thus clear the
  optcounter information by calling those TransactionManager
  methods, like this:
  
   // This code is executing within a transaction that was not
  created by the TransactionManager class.
   // Because the returned TransactionHandle indicates that the
  current transaction was not created by the following call
   // to TransactionManager.begin, the following calls to
  TransactionManager methods do not affect the current
  transaction.
   // However, they now make callbacks to internal WebSphere
  Commerce code as if a transaction was beginning, and ending,
  causing
   // the optcounter information to be cleared by the following
  TransactionManager calls.
  
   TransactionHandle handle = TransactionManager.begin(); //
  Clears optcounter information for this thread.
   try {
       // Code that uses WebSphere Commerce EJB beans executes
  here and accumulates optcounter information for this thread.
       // The maxNoTransactionActive limit is not effective here,
  since the OptCounterinfo class behaves as if the
       // current transaction was created by
  TransactionManager.begin.
       TransactionManager.commit(handle); // Clears optcounter
  information for this thread.
   } catch (Throwable ex) {
       TransactionManager.rollback(handle); // Clears optcounter
  information for this thread.
       throw ex;
   }
  
   -------------------------------------------------------------
   The latest available maintenance information can be obtained
  from the Recommended Fixes for WebSphere Commerce technote:
   http://www.ibm.com/support/docview.wss?rs=3046&uid=swg21261296
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  WC BUS ED ILINU

• Fixed component ID

  5724I3804

Applicable component levels

• R600 PSY

     UP