tag:blogger.com,1999:blog-5430866.post1001856036643590572..comments2024-01-02T08:54:14.406-05:00Comments on Peter Bromberg's UnBlog: ASP.NET : Killer Viewstate Invasionpeterbromberghttp://www.blogger.com/profile/18173639411723574123noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-5430866.post-79315833607111504732009-05-21T05:54:47.380-05:002009-05-21T05:54:47.380-05:00Hi Peter,
Wasn't sure where to post this, but I w...Hi Peter,<br /><br />Wasn't sure where to post this, but I wanted to point out that in the code solution you provide along with the excellent article linked below...<br /><br /><A HREF="http://www.eggheadcafe.com/articles/20040613.asp" REL="nofollow">Storing viewstate server side</A>...there seems to be an issue in the viewstatemngr class, where you declare....<br /><br />private static string SESSION_VIEW_STATE_MGR=System.Web.HttpContext.Current.Session.SessionID.ToString();<br /><br />** please note I am not an expert coder or anything, and I ported this code to vb.net. (so might be a vb.net specific issue) However I found that as its declared static / shared it only uses the first sessionid that is passed, so therefore you only have one cached viewstatemng instance per application as opposed to per user.<br /><br />I did not notice this when testing locally, however when it was used by multiusers, the viewstate would not be accurate and the buttons had to be clicked multiple times to submit.<br /><br />I changed all references to SESSION_VIEW_STATE_MGR<br /><br />to being the actual instance sessionid and is working fine.<br /><br />Again, I think this is an excellent article and i ironically sufferred from copying/pasting and trusting an internet source as oppossed to actually analysing the code in detail, In addition, the problem was not initially evident as I like most cowboy developers tested in a single user environ and expected it to work equally well.<br /><br />Thanks again for the article...SteveBnoreply@blogger.com