Session Affinity
Session Affinity
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.
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.
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.