Unexpected issues with SessionPageStatePersiste
- by geekrutherford
Several iterations ago I implemented the SessionPageStatePersister in an application as a way to cut down on the size of the hidden ViewState input on aspx pages.
At first it seemed utterly fantasic. The size of the ViewState appeared to be drastically reduced and the application did not appear to peform any slower than baseline.
Enter the iFrame & user control. I added a user control which pings the web server every 20 seconds in order to show updated application information to the user (new messages, reports, etc.) After releasing this nifty little control into the QA environment I quickly began receiving emails from testers about "post back" related error messages which mostly centered around invalid ViewState exceptions.
At first I dismissed it as something related to all of the AJAX requests happening on the page and considered turning off page event validation. However, upon further investigation I came across the following article:
Things That You Should Watch Out For When Using SessionPageStatePersister
In this article the author specifically states:
If you application uses frames than each frame request will create a new session view state item and as before it will remove items when reaching the maximum, you come into a situation that one of the frames will probably loose it session view state because other frames did post backs.
Oh snap! That is precisely what I am doing. That combined with multiple users on the application equals dropped ViewStates!
The temporary fix has been to disable the use of the SessionPageStatePersister in my application. This results in a bloated hidden ViewState input, but the web server is no longer tasked with maintaing/retreiving it and the app. no longer loses ViewState information.
