Last post Jul 24, 2009 10:50 AM by mihir.mone
Jul 24, 2009 04:41 AM|mihir.mone|LINK
I have my application hosted in Load Balacing scenario. There are 3 physical servers. (e.g.
I have same application but hosted with a Subdomain on other 2 servers. (e.g.
We use State Server to maintain sessions.
I want to persist Session Variables for the requests for different domains. (www.xxx.com and
Jul 24, 2009 06:12 AM|RickNZ|LINK
As a first step, you should make sure that the session cookie has its Domain property set to ".xxx.com" (note the two dots).
Unfortunately, the default session handlers don't provide direct control over the session cookie. You will therefore either need to catch and adjust it from an HttpModule event handler, or write a customized sessionIDManager.
Jul 24, 2009 06:31 AM|mihir.mone|LINK
Thanks for the reply..
In short, there is no such setting to do so.
I was planning to go with SQL Server for storing sessions.
I hope, It will solve my problem then.
But, I have a query upon your suggestion -
How can a HttpModule can solve my problem with same application (physically stored on different NLB's) with different sub-domains?
How Microsoft must be handling User Session aroung multiple sub-domains?
Jul 24, 2009 09:51 AM|RickNZ|LINK
It would be good to switch to SQL. State Server won't persist any data, so if it fails or recycles, all session data will be lost.
The idea with an HttpModule is to patch up the session cookie so that it has the right Domain property when it's first set. Check the list of cookies in the Response object, and make changes before they are sent to the client. The Session provider uses
that cookie as the key with which the session data is stored and retrieved from whichever session backing store you're using. In order to access the same session, the same cookie must be available on all sites. Each NLB server will receive a cookie along
with an HTTP request.
Microsoft solves this in part by using Passport / Windows Live ID. They have a single back-end site that handles the Authentication, and that site then hands out tokens / cookies to both end users and the websites. That approach makes sense if your sites
don't share a common domain, but in your case they do, so regular cookies is a much easier way to go.
Jul 24, 2009 10:50 AM|mihir.mone|LINK
I must thank you for sharing your knowledge.
Wonderful explaination and a Great Help..