Let us see what happens when you have a web farm. Assume I
am the client and hitting your server X. My session is known to the server X.
Next time I hit the same box X and everything is fine. After about 10-15
minutes, that server is under load and I am redirected to the Server Y.
Naturally, Y will not know who I am and would simply redirect me to the login
page. And the same thing would happen to any person who hits your website. In
this case, we will have to use Out of Process session mode, which could be ASP.NET
State Server or SQL Server. Imagine what would happen if you still end up
losing sessions?
I would suggest checking the following.
1. In IIS, the Web sites names and identifiers must be same
throughout the web farm (NOTE that it is CASE-SenSitive). For more details,
check out the following KB.
2. In your Framework folder (C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG)
there is a machine.config file which contains the following default settings.
<machineKey
validationKey="AutoGenerate,IsolateApps"
decryptionKey="AutoGenerate,IsolateApps"
validation="SHA1"/>
If you are planning to use a Web Farm, you must ensure that
the machineKey’s validationKey and decryptionKey is not set to AutoGenerate.
The following KBs will show you how to do it in VB and C#.
3. If you are not using Web farms, check for Web garden. In
your machine.config (pre Win 2k3 servers) there is an attribute called Web Garden which could be enabled to True. If you plan to keep this to true, you must use
Out Of process as discussed above. In Win 2k3 boxes the web garden
configuration is not read from the Machine.config. Instead, it is taken from
your Application Pool settings. Read
more.
Question 4: Since it is reproducible, the first thing which I
would like to clarify is whether it is a problem with this particular application
or all the applications.
Answer 4: Let us consider the following scenarios.
All the applications exhibit the same behavior. It means
that no application is capable of persisting the session related information.
Oh yes, believe me… this is a possibility!! I have seen this issue happen quite
often due to a bad server name. For example, if your server name has an
underscore or other special characters in it, you will not be able to persist
session or cookie related information. To ensure that you are not hitting this
issue, check the following KB
and ensure that your server name is correctly formed without any Underscores and
other special characters.
Session on all of the pages in your application work fine,
but assume there is a page where you are just unable to persist the session
information. To me, this means that there might be a bad object which is
causing this problem. The first thing I would advise is to create a back up
page for the problematic page. Then, you need to comment all the lines which
are storing anything in session. Once you are done, your page should work fine.
Please check it before continuing. Now, add a dummy session variable and see if
that works. Since all the other pages are working fine, I am pretty sure that
if you create a dummy session variable that would work. Still, it is good to do
this test. Once you have checked the dummy session variable in action, all you
have to do is uncomment the lines containing session 1 by 1 (or may be chunk by
chunk). Test your page each time after you uncomment the page. Pretty soon, you
will come up with a variable which is causing you issues. Fix that object and
you should be good!
Recently, I encountered a very interesting issue. The
sessions were working absolutely fine. This was a shopping cart application and
each time the user browsed to any specific item he was able to add it to the
cookies. His session worked fine until he selected the 20th item. It would
happen each time without fail and happened for no less or more number of items
but 20. I decided to peek into the IIS Logs with the cookie enabled.
I could see that the session ID was showing as following…
ASPSESSIONIDSSAQTADR=PKCFNDFCAJPLBEPHCBJCDNPP.
Each time when he selected a new item it stored a cookie and this was appended
to the above cookie list. Interestingly, after 20 items the ASPSessionID was
removed and we ended up losing the session. I was thinking about why it would
be and then found the following
KB. Notice that it talks about a limit of 20 cookies per unique host or
domain name. So, the bottom-line is that you can end up losing sessions even
though there is a limitation with the client side.
I have been working as an IIS/ASP.NET Technical Lead at
Microsoft since 2004 and I have seen quite a lot of session loss related
issues. Most of the time, I was able to resolve when I followed the above
techniques. I hope that this article comes in handy for you as well.