IBM Support

PK69093: HANG IN APPLICATION CALLS TO STATEFUL SESSION JAVAJBEANS WHEN ACTIVATION AND PASSIVATION OCCUR CONCURRENTLY

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • The primary symptom of this problem is that calls to an
    Enterprise JavaBean do not complete.  This problem only occurs
    for Enterprise JavaBeans that are persisted, it is occurring
    for Stateful Session Enterprise JavaBeans.  The problem occurs
    when the same Enterprise JavaBean instance is being
    passivated and activated at the same time.
    A javacore of the WebSphere Application Server process shows
    a deadlock similar to this one.
    1LKDEADLOCK    Deadlock detected !!!
    NULL           ---------------------
    NULL
    2LKDEADLOCKTHR  Thread "WebContainer : 8" (0x00002AAB38BA8700)
    3LKDEADLOCKWTR    is waiting for:
    4LKDEADLOCKMON      sys_mon_t:0x00002AAB344142C0 infl_mon_t:
    0x00002AAB34414340:
    4LKDEADLOCKOBJ
    java/lang/Object@00002AAAB7417880/00002AAAB7417898:
    3LKDEADLOCKOWN    which is owned by:
    2LKDEADLOCKTHR  Thread "Deferrable Alarm : 3"
    (0x00000000024F6C00)
    3LKDEADLOCKWTR    which is waiting for:
    4LKDEADLOCKMON      sys_mon_t:0x0000000001961618 infl_mon_t:
    0x0000000001961698:
    4LKDEADLOCKOBJ
    com/ibm/ejs/container/passivator/StatefulPassivator@00002AAAB73F
    9240/00002AAAB73F9258:
    3LKDEADLOCKOWN    which is owned by:
    2LKDEADLOCKTHR  Thread "WebContainer : 8" (0x00002AAB38BA8700)
    .
    3XMTHREADINFO      "Deferrable Alarm : 3"
    (TID:0x00000000024F6C00, sys_thread_t:0x00000000024EAB68,
    state:B, native ID:0x0000000000000293) prio=5
    4XESTACKTRACE          at
    com/ibm/ejs/container/StatefulBeanO.passivate(StatefulBeanO.java
    :583(Compiled Code))
    4XESTACKTRACE          at
    com/ibm/ejs/container/activator/StatefulSessionActivationStrateg
    y.atDiscard(StatefulSessionActivationStrategy.java:484(Compiled
    Code))
    4XESTACKTRACE          at
    com/ibm/ejs/container/activator/Activator.discardObject(Activato
    r.java:822(Compiled Code))
    4XESTACKTRACE          at
    com/ibm/ejs/util/cache/Cache.evictObject(Cache.java:1034(Compile
    d Code))
    4XESTACKTRACE          at
    com/ibm/ejs/util/cache/BackgroundLruEvictionStrategy.sweep(Backg
    roundLruEvictionStrategy.java:527(Compiled Code))
    4XESTACKTRACE          at
    com/ibm/ejs/util/cache/BackgroundLruEvictionStrategy.alarm(Backg
    roundLruEvictionStrategy.java:420(Compiled Code))
    .
    3XMTHREADINFO      "WebContainer : 8" (TID:0x00002AAB38BA8700,
    sys_thread_t:0x00002AAB39E681C8, state:B, native
    ID:0x00000000000003BD) prio=5
    4XESTACKTRACE          at
    com/ibm/ejs/container/activator/SingletonActivationStrategy.atGe
    t(SingletonActivationStrategy.java:329(Compiled Code))
    4XESTACKTRACE          at
    com/ibm/ejs/container/activator/Activator.getBean(Activator.java
    :662(Compiled Code))
    4XESTACKTRACE          at
    com/ibm/ejs/container/EJSHome.getBean_Common(EJSHome.java:2447(C
    ompiled Code))
    4XESTACKTRACE          at
    com/ibm/ejs/container/EJSHome.getBean(EJSHome.java:2355(Compiled
    Code))
    4XESTACKTRACE          at
    com/ibm/global/order/cart/EJSBMPglobal_CartHomeBean_dcc4
    719b.findByPrimaryKey(Bytecode PC:2(Compiled Code))
    4XESTACKTRACE          at
    com/ibm/global/order/cart/EJSRemoteBMPglobal_CartHome_dc
    c4719b.findByPrimaryKey(Bytecode PC:56(Compiled Code))
    4XESTACKTRACE          at
    com/ibm/global/order/cart/_CartHome_Stub.findByPrimaryKey
    (_CartHome_Stub.java:292(Compiled Code))
    4XESTACKTRACE          at
    com/ibm/global/util/factory/EJBServiceFactory.findCart(B
    ytecode PC:26(Compiled Code))
    4XESTACKTRACE          at
    com/ibm/global/order/cart/GlobalWebCart.init(Bytecode
    PC:26(Compiled Code))
    4XESTACKTRACE          at
    com/ibm/global/order/cart/GlobalWebCart.readExternal(Byt
    ecode PC:18)
    4XESTACKTRACE          at
    java/io/ObjectInputStream.readExternalData(ObjectInputStream.jav
    a:1768(Compiled Code))
    4XESTACKTRACE          at
    java/io/ObjectInputStream.readOrdinaryObject(ObjectInputStream.j
    ava:1726(Compiled Code))
    4XESTACKTRACE          at
    java/io/ObjectInputStream.readObject0(ObjectInputStream.java:131
    4(Compiled Code))
    4XESTACKTRACE          at
    java/io/ObjectInputStream.defaultReadFields(ObjectInputStream.ja
    va:1927(Compiled Code))
    4XESTACKTRACE          at
    java/io/ObjectInputStream.readSerialData(ObjectInputStream.java:
    1851(Compiled Code))
    4XESTACKTRACE          at
    java/io/ObjectInputStream.readOrdinaryObject(ObjectInputStream.j
    ava:1728(Compiled Code))
    4XESTACKTRACE          at
    java/io/ObjectInputStream.readObject0(ObjectInputStream.java:131
    4(Compiled Code))
    4XESTACKTRACE          at
    java/io/ObjectInputStream.readObject(ObjectInputStream.java:354(
    Compiled Code))
    4XESTACKTRACE          at
    com/ibm/ejs/container/passivator/StatefulPassivator.activate(Sta
    tefulPassivator.java:325(Compiled Code))
    4XESTACKTRACE          at
    com/ibm/ejs/container/StatefulBeanO.activate(StatefulBeanO.java:
    498)
    4XESTACKTRACE          at
    com/ibm/ejs/container/activator/StatefulSessionActivationStrateg
    y.atActivate(StatefulSessionActivationStrategy.java:282(Compiled
    Code))
    4XESTACKTRACE          at
    com/ibm/ejs/container/activator/Activator.activateBean(Activator
    .java:597(Compiled Code))
    

Local fix

  • One possible workaround is increase the EJB cache to reduce the
    frequency of EJB passivation.  But this increases the java heap
    required for the EJB cache.
    .
    Change the ejbPassivate to store the BMP primary key in an
    instance variable during ejbPassivate, and then do the
    findByPrimaryKey for it during ejbActivate, that would avoid the
    problem.
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED:  All users of the IBM?  WebSphere?           *
    *                  Application Server V6.1.0 and               *
    *                  the use of Stateful Session Enterprise      *
    *                  JavaBean (stateful session bean for short). *
    ****************************************************************
    * PROBLEM DESCRIPTION: Deadlock in the Enterprise JavaBeans    *
    *                      Container while passivating and         *
    *                      concurrently activating a stateful      *
    *                      session bean.                           *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    The scenario to hit this issue was as follows:
    
    One stateful session bean is being passivated while at the
    same time another stateful session bean is being activated.
    It is acceptable for beans to be passivated and activated
    at the same time, and is accounted for by the Enterprise
    JavaBeans Container.  However, in the scenario
    there is a very narrow situation which caused this scenario to
    deadlock.  That is, during the activation of the stateful
    session bean, the bean being activated made a call to
    another bean.  Part of the Enterprise JavaBeans Container
    synchronization locks for the requested bean were in use
    by the thread performing the passivation of the other stateful
    session bean.  Therefore, the thread performing the activate
    had to wait for the given lock.  Meanwhile, the thread
    performing the passivation eventually needed a lock held by
    the thread performing the activation, thus the deadlock.
    The key part of this scenario is where the user made a call to
    another bean during the activation of their stateful session
    bean, and the thread associated with the requested bean in turn
    happened to need a lock held by a thread performing the
    passivation of their stateful session bean.  This is not a
    typical scenario and is very hard to hit.
    It is acceptable for the user to make a call to
    another bean from within the activation of their stateful
    session bean and in most cases will never result in a
    deadlock.
    

Problem conclusion

  • Code has been added to account for the deadlock caused
    by the timing issues of the scenario described above.
    
    The fix for this APAR is currently targeted for inclusion in
    Service Level (Fix Pack) 6.1.0.21 of
    WebSphere Application Server version 6.1.0.
    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

    PK69093

  • Reported component name

    WEBS APP SERV N

  • Reported component ID

    5724H8800

  • Reported release

    61A

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2008-07-15

  • Closed date

    2008-09-09

  • Last modified date

    2008-09-09

  • 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

    WEBS APP SERV N

  • Fixed component ID

    5724H8800

Applicable component levels

  • R61A PSY

       UP

  • R61H PSY

       UP

  • R61I PSY

       UP

  • R61P PSY

       UP

  • R61S PSY

       UP

  • R61W PSY

       UP

  • R61Z PSY

       UP

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"6.1","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
29 December 2021