httpSessionContextIntegrationFilter - Need some help understanding it

[suparna]

Hi! I'm still trying to figure out how the httpSessionContextIntegrationFilter work, and the login behaviour incase of a clustered appServer.

Say I have a load balancer and two application servers, once a user logs in and a session is established on a server, what happens when the user gets sent to the second server for subsequent requests? How is the session propogated by the httpSessionContextIntegrationFilter. Does the user have to re-login?

Thanks
Suparna

[ThomasBecker]

You'll need to either replicate the session between all applications in your cluster, which is possible, but is not as trivial as it sounds. There're lots of things to care about.

Or you make your user persistence. Therefore you'll need your loadbalancer either identifying your users via some unique http-header or cookie or your loadbalancer needs to inject cookies (SERVERID=server1).
With this solution your users will stay on the same server, which knows their session. If one server fails, all users on this server will loose their session. But in most cases this disadvantage saves you from many other headaches and torned out hairs.

[Ben Alex]

You could adapt the cookie-based remember-me service to do this, if you didn't want to use HTTP session replication. Most clustered apps I see have (i) sticky load balancing and (ii) no HTTP session replication. It's better to make your load balancer push through requests to the same server as originally handled them, as it saves a lot of overhead in the application server tier.

[ThomasBecker]

Hey Ben,

I fully agree. And it will save you some headaches. Only disadvantage is, that user's will loose their session if one of the hosts fails. Also any patch, etc. which will need a restart/redeploy of the application might cause user's to loose their sessions once (even with sequential update). But this shouldn't be the case to often.

Cheers,
Thomas

[Ben Alex]

It's true that a server failure will cause the user's session to be lost. However, most apps tradeoff this fairly infrequent event for the performance of avoiding HTTP sesson replication.