I've set up app server clones, and am trying to do load-balancing, as well as achieve "server affinity", i.e. if a request belongs to a session, then it should be delegated to the same app server instance with which it is associated. It seems like the only way to achieve "server affinity" is to persist the session info in a database. If the session is not persisted, then WebSphere uses a strict round-robin policy. Is there a way to obtain "server affinity" without persisting it to a database? I have several problems with persistent sessions: 1) Some of my state info is not Serializable 2)Performance issues
We have the same problem too. IBM told us that we have to switch the ose.session.affinity in the bootstrap.properties file to true. But it is not guaranteed that the first clone gets its session back at the second request. IBM says that in normal cases the session affinity works but the 100% guaranty is only when session are stored persistent in a database.
Kyle, I'm using WAS 4.0. I'm observing session affinity only while using persistent sessions. Ok so I understand in WAS 3.5, session affinity was related to session persistence, and that behavior has apparently changed in 4.0. Tracing through the plugin log, it seems like there is a bug where it is unable to correctly parse the JSESSIONID cookie value(and hence the cloneid) from the returned cookies. I also verified this by turning off cookies from the browser and relying solely on explicit URL re-writing. In that case, everything works fine. Has anyone experienced anything similar? Just one more thing. Seems like the documentation for Websphere 4.0 AE at the infocenter has not been updated since it incorrectly says that session affinity can only be achieved by using persistent sessions. [ March 12, 2002: Message edited by: Junaid Bhatra ]