HTTP session problems
Use troubleshooting information for problems when 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.
- HTTP sessions are not getting created, or are lost between requests
- HTTP Sessions are not persistent
- Session is shared across multiple browsers on same client machine
- Session is not getting invalidated immediately after specified session timeout interval
- Unwanted sessions are being created by JavaServer Pages
- Users are not logged out after the HTTP session timer expires
- Exceptions can occur during run time when updating applications where session persistence is enabled
HTTP sessions are not getting created, or are lost between requests
- 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 or update the cookie
settings, in the Modify.
- For example, if the cookie domain is set as
.myCom.com
, resources should be accessed using that domain name. Example: https://www.myCom.com/myapp/servlet/sessionservlet. - If the domain property is set, make sure it begins with a dot (.). An older browser
might not accept cookies if the domain name doesn't start with a dot. Recent browsers honor 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 all browsers honor the cookie.
Note: When the servers are on different hosts, ensure that session cookies flow to all the servers by configuring a front-end router such as a web server with the plug-in or setting the Cookie domain.
, click - For example, if the cookie domain is set as
- Check the Cookie path specified on the SessionManager. Check whether the problem URL is hierarchically beneath 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 the 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. - 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.
- On the browser, enable
- If you are using URL rewriting instead of cookies:
- Ensure there are no static HTML pages on your application's navigation path.
- 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.If you are using SSL as your session tracking mechanism:
- Ensure that you have SSL enabled on your IBM® HTTP Server or iPlanet HTTP server.
- If you are in a clustered (multiple node) environment, ensure that you have session persistence enabled.
HTTP Sessions are not persistent
- 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.
- If you are using Database-based persistence:
- Check the JNDI name of the data source specified correctly on SessionManager.
- Specify correct userid and password for accessing the database.
Note that these settings have to be checked against the properties of an existing data source in the administrative console. The session manager does not automatically create a session database for you.
- The data source should be non-JTA, for example, non XA enabled.
- Check the logs for appropriate database error messages.
- With DB2®, for row sizes other than 4k make sure specified row size matches the DB2 page size. Make sure tablespace name is specified correctly.
- If you are using memory-based persistence (available only in a
network deployment environment):
- Review Memory-to-memory replication.
- 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 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
<% @page session="false" %>
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.
com.ibm.ws.security.web.logoutOnHTTPSessionExpire
property only applies to
applications using form login.- 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.
Exceptions can occur during run time when updating applications where session persistence is enabled
Users who have session persistence enabled and run application updates during run time might experience unexpected exceptions after the application is restarted.
If updates have been made that change the attributes saved, then all the sessions created by the associated application might have to be invalidated prior to the application update if the application can not handle these changes. In this situation, all session objects must be removed from the back-end as well. See the HTTP session invalidation information to learn more about how to remove these sessions properly.
IBM Support has documents and tools that can save you time gathering information needed to resolve problems. Before opening a problem report, see the product Support page: https://www.ibm.com/mysupport/s/topic/0TO500000001DQQGA2/websphere-application-server.