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

 A fix is available

4.0.5: WebSphere Application Server Version 4.0 Fix Pack 5 (Version 4.0.5)



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 symptons 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 supersedes PQ59155 which was opened originally for this
problem but uncovered some other bug in the base version of the
code.
Temporary fix
PQ63816.jar
Comments
APAR information
APAR number PQ68153
Reported component name WEBSPHERE AE SO
Reported component ID 5630A2202
Reported release 400
Status CLOSED PER
PE NoPE
HIPER NoHIPER
Submitted date 2002-11-12
Closed date 2002-11-12
Last modified date 2002-11-12

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

APAR is sysrouted TO one or more of the following:

Modules/Macros
SESSIONS          

SRLS

Fix information
Fixed component name WEBSPHERE AE SO
Fixed component ID 5630A2202

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 #: PQ68153
IBM Group: Software Group
Modified date: Nov 12, 2002