PQ59155: WHEN USING PERSISTENT SESSIONS IN WEBSPHERE, THE SESSION OBJECT IS NOT PUT INTO CACHE UPON CREATION.

A fix is available
PQ63816, 3.5.6: Session object are being cached upon creation

APAR

APAR status
Closed as program error.

Error description
THERE IS A DIFFERENCE IN BEHAVIOR BETWEEN PERSISENT SESSIONS AND
IN MEMORY (CACHE) SESSIONS. WHEN USING IN MEMORY (CACHE)
SESSIONS, THE SESSION OBJECT IS PLACED INTO CACHE IMMEDIATELY
UPON CREATION. HOWEVER, WHEN USING PERSISTENT SESSIONS, THE
SESSION OBJECT IS NOT PUT INTO CACHE UNTIL THE END OF THE
service() METHOD.
THE CODE NEEDS TO BE CHANGED SO THAT WHEN USING PERSISTENT
SESSIONS, THE SESSION OBJECT IS PUT INTO MEMORY (CACHE) UPON
CREATION AND NOT AT THE END OF THE service() METHOD.
Local fix
Problem summary
****************************************************************
* USERS AFFECTED: WebSphere Application Server - Session       *
*                 Manager Users                                *
****************************************************************
* PROBLEM DESCRIPTION: In persistent mode on a session         *
*                      create, the session is not being        *
*                      persisted to the database until the     *
*                      service method ends.                    *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
The symptoms of the problem are that the session object is
returned as a null value on the second request for it.  This
fix will not be helpful if the session object is being returned
as null other than the second request.  With session persistence
enabled, a session object gets created on the first request for
it.  If another request comes for the same session object before
the session manager has been able to persist the object and the
request goes to another clone the session manager will return a
null value because the session object hasn't been persisted yet
and been put within the cache of the first clone.  This
behavior can be seen sometimes even if the second request goes
to the same clone as the first request did since the session
manager puts the session object into the cache only at the end
of the service method.
Problem conclusion
This fix will cause the session object to be inserted in the
cache and persisted to the session database upon session
creation.
Temporary fix
PQ59155
Comments
APAR information
APAR numberPQ59155
Reported component nameWAS ADVANCED SU
Reported component ID5648C8402
Reported release350
StatusCLOSED PER
PENoPE
HIPERNoHIPER
Submitted date2002-03-18
Closed date2002-05-28
Last modified date2002-11-12

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:

PQ68143

Modules/Macros
SESSIONS
APAR is sysrouted TO one or more of the following:PQ68143Modules/Macros

Fix information
Fixed component nameWAS ADVANCED SU
Fixed component ID5648C8402

Applicable component levels
R350 PSYUP











Document Information

Product categories: Software, Application Servers, Distributed Application & Web Servers, WebSphere Application Server, General
Software version: 350
Reference #: PQ59155
IBM Group: Software Group
Modified date: 2002-11-12