IBM Support

PK15508: IsolationLevelChangeException is thrown during a restart of an ejb application.

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • IssolationLevelChangeException occurs when an application
    containing CMP 1.1 EJBs is restarted without restarting the
    WebSphere Server.  This problem is related to applications
    containing 1.1 EJBs only.
    

Local fix

  • Fix is being worked on and will be provided in 6.0.2 service
    pack
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All WebSphere Application Server version 6   *
    *                 applications containing Version 1.1 EJBs.    *
    ****************************************************************
    * PROBLEM DESCRIPTION: IssolationLevelChangeException occurs   *
    *                      when an application containing CMP      *
    *                      1.1 EJBs is restarted without           *
    *                      restarting the WebSphere Applicaiton    *
    *                      Server. This problem is related to      *
    *                      applications containing 1.1 EJBs only.  *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    This problem is somewhat bizzarre and is not easy to get into.
    Here is one scenario that reproduced the problem:
    Have a Stateless Session Bean (SLSB) which calls a finder on
    a CMP 1.1 Entity Bean (EB) on WebSphere Application Server
    version 6.0 (it is important to note that this problem can only
    happen on version 6.0).  You must run thisscenario twice.
    For the first run the SLSB looks up the EB and "caches" a
    copy of the EB home.  When the SLSB looks up the EB, this
    causes the EB to be initialized.  Then call a finder on the
    home.  So far everything works as expected.
    Next, stop and restart ONLY the application containing the EB.
    Then run the scenario again. This time the SLSB doesn't
    need to look up the EB home, rather it uses its "cached"
    instance of the home.  With the cached version of the home,
    the SLSB calls the same finder on the EB.  Calling the method
    on this EB causes the EB to be initialized (it needs to be
    initialized since it was cycled).  The key thing to notice here
    is that in both runs, the EB is initialized which is the
    correct behavior.  However, in the two cases, the path to the
    initialization is slightly different.  In the first case,
    during the home look-up, the current transaction is suspended
    and as such the initialization doesn't run within the user's
    transaction context.  After the look-up completes the
    transaction is resumed.  In the second case, since it didn't
    do a naming look up, the code path is different.  In this
    case the initialization is performed within the user's
    global transaction (that is the current transaction is not
    suspended). The problem with this is that during the
    initialization of the EB, a 'default' isolation level
    (REPEATABLE_READ) is associated with the user's tranaction.
    This is important because after the initialization happens
    the finder is actually called, at which time the isolation
    level (READ_COMMITTED) associated with the finder is attempted
    to be set on the transaction. Since the isolation level
    associated with the transaction is REPEATABLE_READ, an
    exception is thrown because an isolation level can't be changed
    for the life of a transaction (except in the case where the
    isolation level is TRANSACTION_NONE. In that case the isolation
    level can be changed to something else.
    

Problem conclusion

  • By applying this fix, the scenario described above is
    properly handled and an IsolationLevelChangeException
    is not thrown.
    
    The fix for this APAR is currently targeted for inclusion
    in fixpack 6.0.2.9.
    Please refer to the recommended updates page for delivery
    information:
    http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
    

Temporary fix

Comments

APAR Information

  • APAR number

    PK15508

  • Reported component name

    WEBSPH APP SERV

  • Reported component ID

    5724J0800

  • Reported release

    60W

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2005-11-18

  • Closed date

    2006-01-12

  • Last modified date

    2006-01-12

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

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

Modules/Macros

  • EJBCNTR
    

Fix information

  • Fixed component name

    WEBSPH APP SERV

  • Fixed component ID

    5724J0800

Applicable component levels

  • R60A PSY

       UP

  • R60H PSY

       UP

  • R60I PSY

       UP

  • R60P PSY

       UP

  • R60S PSY

       UP

  • R60W PSY

       UP

  • R60Z PSY

       UP

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"6.0","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
19 October 2021