PQ56532: CNTR0021E NON-APPLICATION EXCEPTION OCCURRED ON BEAN. ILLEGALSTATEEXCEPTION RUNNING ECPERF IN OPTIMISTIC MODE

APAR status
Closed as program error.

Error description
The following exception is being thrown while running the
ECPerf ear file in optimistic mode:
CNTR0021E: Non-application exception occurred on bean BeanId
(ECperf_4.02_Cmp_DB2_1.01_ro_opt_v01#mfg.jar#LargeOrderEnt, 3):
java.lang.IllegalStateException
       at com.ibm.ejs.container.EntityBeanO.passivate
          (EntityBeanO.java(Compiled Code))
       at com.ibm.ejs.container.activator.
          (OptCEntityActivationStrategy.java(Compiled Code))
       at com.ibm.ejs.container.activator.Activator.
          rollbackBean(Activator.java(Compiled Code))
       at com.ibm.ejs.container.ContainerTx.afterCompletion
          (ContainerTx.java(Compiled Code))
(stack trace is very long, details are in defect 116394 )
Other information about this test:
1.  The exception only happens about the 10th time doing an add
    or an update.  Other tasks work, like find and delete.
2.  Optimistic has been tested with trade before, but not with
    ECPERF   This is the first time using optimistic w/ ECPERF.
3.  ECPERF pessimistic works on this driver.
4.  Single client fails.
.
After looking at the trace these are the three problems,
in order of importance:
.
1.  ECPERF cannot handle optimistic concurrency as is if all
    of their methods are like the neworder method.  The
    container threw a rollback exception, and ECPerf did not
    retry or handle.  They received the OtherException which
    mapped from the original rollback.  It is always a given
    that multi client optimistic will occassionally get a
    rollback exception.  They simply put up an error page.
    Because of another problem, the container was throwing
    the correct exception which was not handled.
.
2.  The generated deployed code for optimistic caused the
    commit of the transaction to fail, which in turn caused
    the container to rollback the transaction.
.
3.  The container did throw an exception during the passivate
    of an entity bean, and may have not allowed a valid state.
    However, we simply destroy the bean at that point, and it
    did not cause any problem in the scenario.  We were
    already into the rollback from the above exception on the
    commit and continued processing until finally returning
    the correct exception to the client, the transaction rolled
    back mapped to the OtherException by the ECPERF
    application.
Local fix Problem summary
****************************************************************
* USERS AFFECTED: WebSphere Application Server users who wish  *
*                 to use the new Optimistic Concurrency        *
*                 persistence option available starting in     *
*                 WebSphere 4.0.2                              *
****************************************************************
* PROBLEM DESCRIPTION: When the Optimistic Concurrency option  *
*                      is enabled, certain application         *
*                      scenarios may result in the             *
*                      transaction in progress being rolled    *
*                      back, along with the message            *
*                      "Invalid number of predicates on SQL    *
*                      statement" in the application server    *
*                      trace file.                             *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
In certain situations where a bean has been enabled with the
Optimistic Concurrency (also known as Optimistic Locking)
persistence option, the wrong number of SQL predicates were
placed in the SQL statement used to store the data in the
persistent store.  This resulted in an unexpected exception,
causing the transaction that was in progress to be rolled
back.  The message "Invalid number of predicates on SQL
statement" appears as part of the exception.
Problem conclusion
This e-fix, along with e-fix 
PQ57340 for the WebSphere EJB
deployment tool, corrects the problem with the invalid number
of SQL predicates.  To avoid the problem, it is necessary to
apply both this e-fix (PQ56532) and 
PQ57340, and to re-deploy
the EJBs on which the Optimistic Concurrency option has been
enabled.
Temporary fix Comments
APAR information
APAR number PQ56532
Reported component name WEBSPHERE AE NT
Reported component ID 5630A2201
Reported release 400
Status CLOSED PER
PE NoPE
HIPER NoHIPER
Submitted date 2002-01-10
Closed date 2002-02-01
Last modified date 2002-02-01

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Modules/Macros
CONTAINR          

Fix information
Fixed component name WEBSPHERE AE NT
Fixed component ID 5630A2201

Applicable component levels
R400 PSY    UP


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > General
Operating system(s):
Software version: 400
Software edition:
Reference #: PQ56532
IBM Group: Software Group
Modified date: Feb 1, 2002