PQ56060: WHEN USING EXCLUSIVE TYPE A LOCKING, CUSTOMER APPLICATION HANGS AS LOAD INCREASES

APAR status
Closed as program error.

Error description
When customer application uses exclusive type A locking, their
application hangs under load. In container trace received from
the customer, it shows a behavior where a lock is acquired by a
thread that was owned by a thread that was releasing the lock,
but had not yet released the lock, yet the lock does
get
released in the next trace entries. However, at this point all
users requesting this same lock hang.
Local fix Problem summary
****************************************************************
* USERS AFFECTED: All WebSphere Application Server Users       *
****************************************************************
* PROBLEM DESCRIPTION: Cumulative APAR for 4.0 for the         *
*                      EJB container.                          *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
Cumulative Container APAR for 4.0
Problem conclusion
This Container E-fix is cumulative for 4.0


The following defects were fixed in this E-fix:

1) (APAR PQ44001)
 Description of problem:

  WAS 3.5 is throwing different security
                exceptions then WAS 3.0.2.
  It seems that specific exceptions that were
                seen in 3.0.2 arebeing replaced by a more
                general rollback exception in 3.5.

2) (APAR PQ46998)
 Description of problem:

   Strange passivation/timeout behaviour -
  incorrect cache time out

               This fix ensures that the the caching of the
                stateful session beans would not follow the
                cache count set in the container properties.

3) (APAR PQ48160)
 Description of problem:

   Ensures that the proper "stub" type is
                returned for object references to EJBs

  Symptoms of problem include some include
                NotSerializableExceptions during
  marshalling of return arguments where an EJB
                reference is returned.  Also
  some types of "Unable to read value from
                underlying bridge" errors.

  Changes were made to classes related to EJB
                container to correct the problem.

4) (APAR PQ50116)
 Description of problem:

  RemoveException trying to remove stateless
                session bean

  A call to remove() on a stateless session
  bean within a transaction wil cause the error
                "Cannot remove session bean within a
  transaction.

  This efix removes the transaction restriction,
  thus allowing the remove() with a transaction
  to succeed.

5) (APAR PQ52534)
 Description of problem:

  IsolationLevel causes Exception during
  ejbCreate

  This fix ensures that the home methods for
  session beans are performed in an
  "unspecified transaction"
  mode, which ensures that isolation levels to
  not conflict. It now includes a fix for the
  StatefulSessionActivationStrategy, and the
  FileBeanStore which allows for successful
  passivation and removal of stateful session
  beans.


6) (APAR PQ52564)
 Description of problem:

  Proper cleanup not taking place during a
  transaction rollback with Option A caching.

  The problem here stems from the use of Option
  A caching (Exclusive  database access).
  With Option A caching in use, the application
  server assumes that it is the only thing that
  touches the database (i.e.nothing else can
  modify the data outside of the EJB Container,
  not even another clone of the
  EJB Container). In a scenario where a
  transaction encounters a problem and attempts
  to rollback.
  During this rollback,the locks on the database
  are removed and the EJB is released. However,
  the cache does not release the locks on the
  EJB.  Thus, when another (second) client tries
  to call that EJB, it shows
  as locked, because the released EJB is still
  locked in the cache.

7) (APAR PQ53065)
 Description of problem:

  Backport 4.0 Option A caching fixes.

  Several Option A caching issues have been
  addressed in WebSphere 4.0.
  This efix backports to 3.5 these fixes.

NOTES:

This E-Fix must be installed simultaneously on all systems
which interoperate at the EJB level (clients as well as
servers).
Temporary fix
PQ53065.jar
Comments
APAR information
APAR number PQ56060
Reported component name WEBSPHERE AE AI
Reported component ID 5630A2200
Reported release 400
Status CLOSED PER
PE NoPE
HIPER NoHIPER
Submitted date 2001-12-18
Closed date 2001-12-18
Last modified date 2003-04-29

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

APAR is sysrouted TO one or more of the following:

Modules/Macros
CONTAINR          

Fix information
Fixed component name WEBSPHERE AE AI
Fixed component ID 5630A2200

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 #: PQ56060
IBM Group: Software Group
Modified date: Apr 29, 2003