Session Affinity

"JSESSIONID Cookie Format - In a clustered environment, the JSESSIONID cookie is composed of the core Session ID and a few other components. Here's an example:

Cache ID
Session ID
seperator
Clone ID or Partition ID

A Partition ID is appended to the cookie if memory-to-memory replication in peer-to-peer mode is utilized for Distributed Session management. Otherwise, a Clone ID is appended.

Session Affinity and Failover
The Clone/Partition ID corresponds to whichever cluster member creates the Session, and the plug-in is responsible to send that session to the same cluster member as long as it is available. From the Scalability Redbook: "Since the Servlet 2.3 specification, as implemented by WebSphere Application Server V5.0 and higher, only a single cluster member may control/access a given Session at a time. After a Session has been created, all following requests need to go to the same application server that created the Session. This Session affinity is provided by the plug-in. If on a subsequent request the specified cluster member is unavailable,  the plug-in will choose another cluster member and attempt to connect to that. If Distributed Sessions are configured, via database persistence or memory-to-memory replication, the Session will be resumed in-progress on that new member. If not, a new Session will be created and the user's progress will be lost."

If a new cluster member is able to resume the existing Session, it will append its own Clone/Partition ID to the existing JSESSIONID cookie. For instance:

JSESSIONID=0000A2MB4IJozU_VM8IffsMNfdR:v544d0o0:v544d031

Now the plug-in knows that two different cluster members could potentially service this Session. If the original member becomes available again, the Session will switch back to it. Finally, note that according to the System Management Redbook: WebSphere provides session affinity on a best-effort basis. There are narrow windows where session affinity fails. These windows are:

When a cluster member is recovering from a crash, a window exists where
concurrent requests for the same session could end up in different cluster
members 

A server overload can cause requests belonging to the same session to
go to different cluster members"

The above is reformatted of the following IBM link: IBM Developer Article on JSESSIONID and WAS Session Management

The following link is an IBM Infocenter article to configure ODR for WebSphere Virual Enterprise. Configure ODR for Session Afinity - you do not normally have to do this unless for the reasons mentioned in the document.

Sunil Partil has a good and concise article in his WebSphere Notes - Session Management - it points out in a clustered environment how the web server plugin use clone ID or partition ID to ensure session affinity.