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 fixProblem 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 number | PQ53065 | Reported component name | WAS ADVANCED AI | Reported component ID | 5648C8400 | Reported release | 350 | Status | CLOSED PER | PE | NoPE | HIPER | NoHIPER | Submitted date | 2001-10-03 | Closed date | 2001-11-27 | Last modified date | 2002-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 APAR is sysrouted TO one or more of the following:PQ56060Modules/Macros
|
Fix information |
Fixed component name | WAS ADVANCED AI | Fixed component ID | 5648C8400 |
Applicable component levels | R350 PSY | UP |
|