Problems creating or using HTTP sessions
Note: To view and update the Session Manager settings discussed
here, use the administrative console. Select the application server that hosts
the problem application, then under Additional properties, select Web
Container, then Session manager.
What kind of problem are you having?
If your problem is not described here, or none of these steps fixes the
problem:
HTTP Sessions are not getting created, or are
lost between requests
By default, the Session Manager uses cookies
to store the session ID on the client between requests. Unless you intend
to avoid cookie-based session tracking, ensure that cookies are flowing between
WebSphere Application Server and the browser:
- Make sure the Enable cookies checkbox is checked under the Session
tracking Mechanism property.
- Make sure cookies are enabled on the browser you are testing from or from
which your users are accessing the application.
- Check the Cookie domain specified on the SessionManager (to view the or
update the cookie settings, in the Session tracking mechanism->enable cookies property,
click Modify).
- For example, if the cookie domain is set as ".myCom.com", resources should
be accessed using that domain name, e.g. http://www.myCom.com/myapp/servlet/sessionservlet.
- If the domain property is set, make sure it begins with a dot (.). Certain
versions of Netscape do not accept cookies if domain name doesn't start with
a dot. Internet Explorer honors the domain with or without a dot. For example,
if the domain name is set to mycom.com, change it to .mycom.com so
that both Netscape and Internet Explorer honor the cookie.
- Check the Cookie path specified on the SessionManager. Check whether
the problem url is hierarchially below the Cookie path specified. If not correct
the Cookie path.
- If the Cookie maximum age property is set, ensure that the client
(browser) machine's date and time is the same as the server's, including the
time zone. If the client and the server time difference is over the "Cookie
maximum age" then every access would be a new session, since the cookie will
"expire" after the access.
- If you have multiple web modules within an enterprise application that
track sessions:
- If you want to have different session settings among web modules in an
enterprise application, ensure that each web module specifies a different
cookie name or path, or
- If Web modules within an enterprise application use a common cookie name
and path, ensure that the HTTP session settings, such as Cookie maximum age,
are the same for all Web modules. Otherwise cookie behavior will be unpredictable,
and will depend upon which application creates the session. Note that this
does not affect session data, which is maintained separately by Web module.
- Check the cookie flow between browser and server:
- On the browser, enable "cookie prompt". Hit the servlet and make sure
cookie is being prompted.
- On the server, enable SessionManager
trace. Enable tracing for
the HTTP Session Manager component, by using the trace specification "com.ibm.ws.webcontainer.httpsession.*=all=enabled".
After trace is enabled, excericise your session-using servlet or jsp, then
follow the instructions for dumping and browsing the trace output .
- Access the session servlet from the browser.
- The browser will prompt for the cookie; note the jsessionid.
- Reload the servlet, note down the cookie if a new cookie is sent.
- Check the session trace and look for the session id and trace the request
by the thread. Verify that the session is stable across web requests:
- Look for getIHttpsession(...) which is start of session request.
- Look for releaseSesson(..) which is end of servlet request.
- If you are using URL rewriting instead of cookies:
- Ensure there are no static HTML pages on your application's navigation
path.
- Ensure that your servlets and
jsp files are implementing URL rewriting correctly. For details and an example
see Session tracking options.
- If you are using SSL as your session tracking mechanism:
- If you are in a clustered (multiple node) environment, ensure that you
have session persistence enabled.
HTTP Sessions are not persistent
If
your HTTP sessions are not persistent, that is session data is lost when the
application server restarts or is not shared across the cluster:
- Check the Datasource.
- Check the SessionManager's Persistence Settings properties:
- If you intend to take advantage of Session Persistence, verify that Persistence
is set to Database or Memory
to Memory Replication.
- If you are using Database-based persistence:
- If you are using memory-based
persistence, available in a network-deployment (multiple application server)
configuration only:
- Review .
- Review the Internal Replication Domains properties of your Session
manager.
Session is shared across multiple browsers on
same client machine
This behavior is browser-dependent. It varies
between browser vendors, and also may change according to whether a browser
is launched as a new process or as a subprocess of an existing browser session
(for example by hitting Ctl-N on Windows).
The Cookie maximum age property
of the Session Manager also affects this behavior, if cookies are used as
the session-tracking mechanism. If the maximum age is set to some positive
value, all browser instances share the cookies, which are persisted to file
on the client for the specified maximum age time.
Session is not getting invalidated immediately
after specified Session timeout interval
The Session Manager invalidation
process thread runs every x seconds to invalidate any invalid sessions,
where x is determined based on the Session timeout interval specified in the
Session manager properties. For the default value of 30 minutes , x is
around 300 seconds. In this case, it could take up to 5 minutes (300 seconds)
beyond the timeout threshold of 30 minutes for a particular session to become
invalidated.
Unwanted sessions are being created by JSPs
As
required by the JavaServer Page specification, jsps by default perform a request.getSession(true),
so that a session is created if none exists for the client. To prevent JSPs
from creating a new session, set the session scope to false in the
JSP file using the page directive as follows:
<% @page session="false" %>
For current information available from IBM Support on known problems
and their resolution, see the IBM Support
page.
IBM Support has documents
that can save you time gathering information needed to resolve this problem.
Before opening a PMR, see the IBM Support
page.

Troubleshooting by task: What are you trying to do?
Troubleshooting by component: What is not working?
Searchable topic ID:
rtrb_httpsessprobs
Last updated: Jun 21, 2007 8:07:48 PM CDT
WebSphere Business Integration Server Foundation, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.wasee.doc/info/ee/ae/rtrb_httpsessprobs.html