|
| Problem | Session Affinity is not established on the first attempt in WebSphereŽ Application Server V3.5 releases. | | Cause | An explanation of the relationship between session affinity and session persistence. | | Solution | In WebSphere Application Server V3.5 releases, the affinity to a clone is not guaranteed to be established on the first attempt:
- The hash function in the HTTP Server Plugin will route the first request from a user to an available clone.
- The second request from the same user can get routed to any one of the available clones.
- The session affinity is established from then on to the clone that served the second request.
Due to the fact that session affinity is established at the second request, it is important that session persistence be enabled. In other words, session affinity in V3.5 releases will work only when session persistence is enabled. This has been changed in V4 releases where session affinity is established at the first attempt and therefore session persistence is not necessary. In release V4 or V3.5, session persistence should be enabled if failover is important to your environment.
The affinity is only "best-effort".
For example:
- clone 1 has session affinity established to a user session
- clone 1 is stopped for some reason
- on the next request, an alternate clone will be selected, through mediation in the plugin
| |
| |
| |
|
Product categories: Software, Application Servers, Distributed Application & Web Servers, WebSphere Application Server, Sessions and Session Management Operating system(s): Multi-Platform Software version: 3.5 Software edition: Advanced Reference #: 1052245 IBM Group: Software Group Modified date: 2004-03-03
(C) Copyright IBM Corporation 2000, 2004. All Rights Reserved.
|