You may want to first read about the difference between a session and a cookie.
There are two session or cookie management levels. You can set the session or cookie management settings at the application server level, or at the application level. The settings at the application level will take precedence over the settings at the application server level.
- In the left panel of the WebSphere web console, expand Application > Application Types, and select Websphere enterprise applications.
- Select an application.
- Select Session management.
- In the left panel of the WebSphere web console, expand Server > Server Types, and select Websphere applications servers.
- Select an application server.
- Select Session management.
Session tracking mechanism
In the Session tracking mechanism section, by default, only Enable cookies is enabled.
When enable cookies is selected, a cookie will be created on the client PC when requesting the app running on WebSphere in the browser. By default, the cookie is named JSESSIONID. In this example, the session ID (0001ngigW0ETRpuIwfKKzcufWkA:1c4gskmd0) was obtained from the cookie which was created when the web app was requested in the browser.
Enable cookies will take precedence over Enable URL rewriting. When Enable cookies is checked, the session ID will attempt to be obtained from a cookie.
Enable SSL ID tracking will take precedence over Enable cookies and Enable URL rewriting. When Enable SSL ID tracking is enabled, the session ID will attempt to be obtained from SSL information.
Enable URL rewriting - When Enable URL rewriting is enabled, the session ID will attempt to be obtained from the URL. If Enable protocol switch rewriting is enabled, the session ID will attempt to be retained when switching from HTTP to HTTPS, and vice versa.
By default, Security integration is enabled. When enabled, this option associates the a user identity with their HTTP session.
Distributed environment settings
Distrubuted sessions is the idea of distributing sessions across two or more application servers or applications in a cluster.
By default, a WebSphere application server uses session affinity. Session affinity allows WebSphere to assoicate requests from a certain browser to a certain JVM. For example, let's say you have two JVMs in a cluster. When a browser requests an application from the cluster, either JVM1 or JVM2 will send the browser the application. If JVM1 is the application server to send the browser the application, subsequent requests from the browser will route to JVM1, and will not invole JVM2. Likewise, if JVM2 were to send the application to the browser, then JVM2 would continue to answer the browsers requests, until the session is destroyed.
Session affinity improves performance, by allowing sessions to be accessed from cache in the application server, instead of having requests bounce between different application servers in a cluster.
Session affinity can be verified by checking the application server SystemOut.log file. When session affinity has been estabished with JVM1, only JVM1 SystemOut.log file should contain events from the browser. The same is true for JVM2.
~]# $was_home/profiles/<profile name>/servers/JVM1/logs/SystemOut.log ~]# $was_home/profiles/<profile name>/servers/JVM2/logs/SystemOut.log