PQ53065: WHEN USING EXCLUSIVE TYPE A LOCKING CUSTOMER APPLICATION HANGS AS LOAD INCREASES HANG HANGING EXCLUS LOCK


APAR

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 but 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 3.5.4, 3.5.5 for    *
*                      the EJB container.                      *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
Cumulative Container APAR for 3.5.4, 3.5.5.
Problem conclusion
This Container E-fix is cumulative for 3.5.4 and may work for
3.5.3.
All 3.5.3, or later, non-custom Container E-fixes are included
in this E-fix.

The following defects were fixed in this E-fix:

1) (APAR PQ44001)
 Description of problem:The following defects were fixed in this E-fix: 1) (APARPQ44001)
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:Description of problem:WAS 3.5 is throwing different securityexceptions then WAS 3.0.2.It seems that specific exceptions that wereseen in 3.0.2 arebeing replaced by a moregeneral rollback exception in 3.5., 2) (APARPQ46998)
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:Description of problem:Strange passivation/timeout behaviour -incorrect cache time outThis fix ensures that the the caching of thestateful session beans would not follow thecache count set in the container properties., 3) (APARPQ48160)
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:Description of problem:Ensures that the proper "stub" type isreturned for object references to EJBsSymptoms of problem include some includeNotSerializableExceptions duringmarshalling of return arguments where an EJBreference is returned. Alsosome types of "Unable to read value fromunderlying bridge" errors.Changes were made to classes related to EJBcontainer to correct the problem.4) (APAR PQ50116)
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:Description of problem:RemoveException trying to remove statelesssession beanA call to remove() on a stateless sessionbean within a transaction wil cause the error"Cannot remove session bean within atransaction.This efix removes the transaction restriction,thus allowing the remove() with a transactionto succeed., 5) (APARPQ52534)
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:Description of problem:IsolationLevel causes Exception duringejbCreateThis fix ensures that the home methods forsession beans are performed in an"unspecified transaction"mode, which ensures that isolation levels tonot conflict. It now includes a fix for theStatefulSessionActivationStrategy, and theFileBeanStore which allows for successfulpassivation and removal of stateful sessionbeans., 6) (APARPQ52564)
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:Description of problem:Proper cleanup not taking place during atransaction rollback with Option A caching.The problem here stems from the use of OptionA caching (Exclusive database access).With Option A caching in use, the applicationserver assumes that it is the only thing thattouches the database (i.e.nothing else canmodify the data outside of the EJB Container,not even another clone of theEJB Container). In a scenario where atransaction encounters a problem and attemptsto rollback.During this rollback,the locks on the databaseare removed and the EJB is released. However,the cache does not release the locks on theEJB. Thus, when another (second) client triesto call that EJB, it showsas locked, because the released EJB is stilllocked in the cache.7) (APAR PQ53065)
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:Description of problem:Backport 4.0 Option A caching fixes.Several Option A caching issues have beenaddressed in WebSphere 4.0.This efix backports to 3.5 these fixes.
This E-Fix must be installed simultaneously on all systems which interoperate at the EJB level (clients as well as servers).
NOTES:This E-Fix must be installed simultaneously on all systemswhich interoperate at the EJB level (clients as well asservers).
Temporary fix
PQ53065.jar
Comments
APAR information
APAR numberPQ53065
Reported component nameWAS ADVANCED AI
Reported component ID5648C8400
Reported release350
StatusCLOSED PER
PENoPE
HIPERNoHIPER
Submitted date2001-10-03
Closed date2001-11-27
Last modified date2002-05-28

APAR is sysrouted FROM one or more of the following:

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

PQ56060

Modules/Macros
CONTAINR
APAR is sysrouted TO one or more of the following:PQ56060Modules/Macros

Fix information
Fixed component nameWAS ADVANCED AI
Fixed component ID5648C8400

Applicable component levels
R350 PSYUP











Document Information

Product categories: Software, Application Servers, Distributed Application & Web Servers, WebSphere Application Server, General
Software version: 350
Reference #: PQ53065
IBM Group: Software Group
Modified date: 2002-05-28