6.3.1 Session management and failover inside the plug-in

As you know, the plug-in always attempts to route a request that contains session information to the application server that processed the previous requests. However, if the server that contains the session is not available to the plug-in when it forwards the request, then the plug-in can route the request to an alternate server. The alternate server can then retrieve the distributed session information according to the chosen distribution method (database or memory-to-memory replication).

There are three methods of identifying a user's session to the application server: Cookies, URL rewriting, and SSL ID. Example 6-1 shows a JSESSIONID cookie, which consists of four parts:

Example 6-1 Example of a session identifier - JSESSIONID cookie 

JSESSIONID=0000A2MB4IJozU_VM8IffsMNfdR:v544d0o0

In case of a failover, the clone ID of the failover server is appended at the end, also separated by a colon. When the original server becomes available again, the request falls back and is handled by the original server.

Figure 6-2 and the subsequent step-by-step explanation explain how the plug-in performs the failover.

Figure 6-2 Session management example

Using Figure 6-2, the steps involved to find a failover application server are:

1.xxxx

The plug-in processes a request from user A to http://http1/snoop. The request also contains a JSESSION cookie with a session ID and clone ID of v544d031.

2.xxxx

The plug-in matches the virtual host and URI to the cluster wascluster01 (composed by servers wasmember01 and wasmember03, each one located in a different machine).

3.xxxx

The plug-in checks for session affinity and finds the clone ID of v544d031 in the request's JSESSIONID cookie.

4.xxxx

The plug-in searches for the clone ID of v544d031 in the plug-cfg.xml's list of primary servers and matches the clone ID to the wasmember01 application server.

5.xxxx

The plug-in checks to see whether wasmember01 has been marked down. In our case, it has not been marked down yet.

6.xxxx

The plug-in attempts to get a stream to wasmember01. Finding the server is not responding, Web1 is marked as down and the retry timer is started.

7.xxxx

The plug-in checks the session identifier again.

8.xxxx

The plug-in checks the servers. When it reaches wasmember01, it finds that it is marked down and the retry timer is not 0, so it skips wasmember01 and checks the next cluster member in the primary server list.

9.xxxx

The plug-in selects wasmember03 (clone ID v544d0o0) and attempts to get a stream to it. The plug-in either opens a stream or gets an existing one from the queue.

10.xxxx

The request is sent and received successfully to wasmember03 (which retrieves the session information from the persistent session database or has it in-memory because of a previous replication) and sent back to user A.

For additional information about plug-in failover behavior, read WebSphere plug-in behavior in Chapter 6 of WebSphere Application Server V6 Scalability and Performance Handbook, SG24-6392. This section discusses many failure situations in detail and includes information about logs and traces.
xxxx