Session Affinity

Way of sessions working:

Session ID Allows to keep track of individual users

*  Session ID generated on first request and send back to browser with first response.

*  Session ID then arrives with each subsequent request

*  Cookies, URL rewriting and SSL (if request is on HTTPS) are ways to track the session IDs

Session Affinity:

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.

 Plug-in Session Affinity is handled by the WebSphere Plug-in

through a special cookie enabled and configured by the Application

Server

 Default name for the Application Server session cookie is

JSESSIONID

 Application Server Session JSESSIONID cookie is enabled and set

through WebSphere Administration console

 Application servers -> <Application ServerName> -> Session

management -> Cookies

Plug-in Session Affinity

 JSESSIONID cookie contains

CacheID

SessionID

CloneID

 Only CloneID is used by WebSphere Plug-in for Session

Affinity

Plug-in Session Affinity

 For Session Affinity to work a few things must be setup

1. Cluster environment is created

2. JSESSIONID Cookie is enabled by the Application

Server

3. CloneID is generate to the Plugin-cfg.xml , after

Cookie has been setup and Enabled in the Application

Server

ypes of session affinity

A load balancer group supports the following types (or modes) of session affinity:

• Passive
• Active
• Active-conditional

1.Passive session affinity

Passive session affinity can be used with only WebSphere servers

2.Active session affinity

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

3.Active-conditional session affinity

Active-conditional session affinity is for non-WebSphere servers that use cookies.