What is Session affinity?

In a clustered environment, any HTTP requests associated with an HTTP session must be routed to
the same Web application in the same JVM. This ensures that all of the HTTP requests are processed
with a consistent view of the users HTTP session. (Or)

Session Affinity allows returning requests to be routed back to the same server in a cluster that
handled the initial request, if that same server is available. (Or)

Session affinity overrides the load-balancing algorithm by directing all requests in a session to a
specific application server. For some applications to work correctly, the application requires session
affinity between the client and the application server.

WebSphere assures that session affinity is maintained in the following way:

1. Each server ID (ex., server1) is appended to the session ID. When an HTTP session is created, its
ID is passed back to the browser as part of a cookie or URL encoding.
2. When the browser makes further requests, the cookie or URL encoding will be sent back to the
Web server.
3. The Web server plug-in examines the HTTP session ID in the cookie or URL encoding, extracts the
unique ID of the cluster member handling the session, and forwards the request.
The JSESSIONID cookie can be divided into 5 parts:
Cache ID, session ID, separator, clone ID, and partition ID.

Table show their mappings based on the example in Figure 3. A clone ID is an ID of a cluster
member. Table 1 Cookie mapping

The application server ID can be seen in the Web server plug-in configuration file, plug-in-cfg.xml
file, as shown below.

<?xml version="1.0" encoding="ISO-8859-1"?><!--HTTP server plugin

config file for the cell ITSOCell generated on 2004.10.15 at 07:21:03
PM BST-->
<Config>
......
<ServerCluster Name="MyCluster">
<Server CloneID="vuel491u" LoadBalanceWeight="2"
Name="NodeA_server1">
<Transport Hostname="wan" Port="9080" Protocol="http"/>
<Transport Hostname="wan" Port="9443" Protocol="https">
......
</Config>

4. By default, session affinity is enabled for load balancer groups.

5. With session affinity, the application server that handles the first client request generates session
information and places it in a Set-Cookie header in the response. The client inserts this information
in a Cookie header in all future requests in this session with this application server.

Additional information:
Types of session affinity
A load balancer group supports the following types (or modes) of session affinity:
1. Passive
2. Active
3. Active-conditional
Note: Although session affinity applies to both static and dynamic configurations, you must use a
static configuration for active or active-conditional session affinity for non-WebSphere servers.

Passive session affinity: Passive session affinity can be used with only WebSphere servers.

Active session affinity: Active session affinity is for non-WebSphere servers that do not use cookies.

Active-conditional session affinity: Active-conditional session affinity is for non-WebSphere servers

that use cookies.