You may want to first read about the difference between a session and a cookie.
A session ID is created when a WebSphere application is opened in a web browser and by default, the session is destroyed when the web browser is closed (this can be changed). WebSphere has 3 session tracking mechanisms. By default, only Enable cookies is enabled.
How sessions are created is controlled at Application > Application Types > Websphere enterprise applications > select an application > Session management or at Server > Server Types > Websphere applications servers > select an application server > Session management. The settings at the application level will take precedence over the settings at the application server level.
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 (0000a12dvSZHLFhx0hIWFJYVC_-:-1) was obtained from the cookie which was created when the web app was requested in the browser. Likewise, you can display the session ID in Java.
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