I received an email this week from one of our internal development groups stating their Captcha control was not displaying properly. Further analysis revealed different components of this control and its lifecycle were stored in ASP.NET Session. First thing that comes to mind is to check the web.config to ensure the SQL state settings are identical across all four servers (there are four). There were no noticeable issues and everything was identical and configured properly.
I started thinking back to an issue I had several years ago where the IIS web site ID had to be identical for all farm members in order for session state to work properly. Considering that was back in the .NET 1.0/1.1 days, I figured this was no longer an issue. Pulled up the Microsoft Support article (KB325056) and gave it a quick read. At the bottom, it states the following:
So, this certainly could not be an issue with my .NET 2.0+ application, could it???
I wrote a quick session.aspx test page and dropped it on the production servers. I noticed that both server A and server B were writing to their own session and not sharing with servers C and D. However, C and D were sharing. Took a closer look at the web site ID’s for A and B, they were different. However, server C and D were identical. Seems to me the web site ID is still relevant and MUST be identical across the farm. Looking in the SQL tables for state management reveals the following:
Clearly the ID/AppName is still critical to ASP.NET session management. Considering there are four servers in the farm, there should only be one /lm/w3svc/* column. I can clearly see the other members and their specific AppId which ties them to sessions outside the farm. We synced up the ID’s and now session is working as it should.
Take note Microsoft and be sure to update the article to include newer versions of .NET…
No comments:
Post a Comment