This article provides troubleshooting information related
to creating or using Hypertext Transfer Protocol (HTTP) sessions.
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 check box 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).
- Check the Cookie path specified on the SessionManager.
Check whether the problem URL is hierarchically 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 expires 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
is unpredictable, and depends 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.session.*=all=enabled".
After trace is enabled, exercise 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 prompts 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 releaseSession(..) 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.
Deprecated feature: Session tracking using the SSL ID is
deprecated in WebSphere Application Server version 7.0.
You can configure session tracking to use cookies or modify the application
to use URL rewriting.
depfeat
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 data source.
- Check the session manager's persistence settings properties:
- If you intend to take advantage of session persistence, verify
that Persistence is set to Database.
- Persistence could also be set to Memory-to-Memory
Replication.
- If you are using Database-based persistence:
- If you are using memory-based
persistence (available only in a network deployment environment):
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
SessionManager 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 JavaServer Pages
As required by the JavaServer Pages
(JSP) specification, JSP pages by default perform a request.getSession(true),
so that a session is created if none exists for the client. To prevent
JSP pages from creating a new session, set the session scope to
false in
the
.jsp file using the page directive as follows:
<% @page session="false" %>
Session
data intended for one client is seen by another client
In
rare situations, usually due to application errors, session data intended
for one client might be seen by another client. This situation is
referred to as session data crossover. When the DebugSessionCrossover custom
property is set to true, code is enabled to detect and log instances
of session data crossover. Checks are performed to verify that only
the session associated with the request is accessed or referenced.
Messages are logged if any discrepancies are detected. These messages
provide a starting point for debugging this problem. This additional
checking is only performed when running on the WebSphere-managed dispatch
thread, not on any user-created threads.
For
additional information on how to set this property, see article, Web container custom properties.
Users
are not logged out after the HTTP session timer expires
If
users of WebSphere Application Server log onto an
application and sit idle longer than the specified HTTP session timeout
value, the user information is not invalidated and user credentials
stay active until LTPA token timeout occurs.
After you apply
PK25740, complete the following steps to log out users from the application
after the HTTP session has expired.
- In the administrative console, click Security >
Global security.
- Under Custom properties, click New.
- In the Name field, enter com.ibm.ws.security.web.logoutOnHTTPSessionExpire.
- In the Values field, enter true.
- Click Apply and Save to save the changes to your configuration.
- Resynchronize and restart the server.
Unexpected re-authentications: When
you set the com.ibm.ws.security.web.logoutOnHTTPSessionExpire custom
property to true, unexpected re-authentications might occur when you
are working with multiple Web applications. By default, each Web application
has its own unique HTTP session, but the Web browser has one session
cookie. To address this issue, you can change the HTTP session configuration
by giving each application a unique session cookie name or path setting.
As a result, each application gets its own session cookie. Alternatively,
you can configure multiple Web applications with the same enterprise
application to share the same HTTP session. For more information,
see the Assembling so that session data can be shared topic.
IBM Support has documents and tools that can
save you time gathering information needed to resolve problems as
described in
Troubleshooting help from IBM. Before opening
a problem report, see the Support page: