6.8.1 Session affinity

 

+

Search Tips   |   Advanced Search

 

The Servlet 2.3 specification defines that, after a session has been created, all following requests need to go to the same appserver that created the session.

However, in a clustered environment, there is more than one appserver that can serve the client request. Therefore, the plug-in needs to read a request and be able to identify which cluster member should handle it.

Session identifiers are used to do this; they allow the plug-in to pick the correct cluster member and the Web container to retrieve the current session object.

JSESSIONID=0000A2MB4IJozU_VM8IffsMNfdR:v544d0o0

The JSESSIONID cookie can be divided into four parts:

Content	Value used in the example
Cache ID	0000
Session ID	A2MB4IJozU_VM8IffsMNfdR
Separator	:
Clone ID (cluster member) ...or... Partition ID	v544d0o0

A clone ID is the ID of a cluster member...

<Server CloneID="vtnul4vu" 
        ConnectTimeout="0" 
        ExtendedHandshake="false" 
        LoadBalanceWeight="2" 
        MaxConnections="-1" 
        Name="app1Node_Web1" 
        WaitForContinue="false">

There is a new processing logic in WebSphere V6 which is based on the so-called partition ID. JSESSIONID will include a partition ID instead of a clone ID when memory-to-memory replication in peer-to-peer mode is selected. Typically, the partition ID is a long numeric number.

Next