Tag Archives: View State

Invalid View State error While expanding your Web Farm

Posted on by

Last few days back, I faced one peculiar issue, while adding a new system in my Web Farm. My users started facing an issue “InValid View State” intermittently.

First, I could not guess what is the issue and thought of some programming issue. But later after analysis I found the issue is caused by the changes in the Web Farm.

Just before discuss the solution, Let’s analyse this.

First,  What is Web Farm?

A Web Farm is used in highly available applications and which have a lot of users that cannot be served by a single server. They provides better performance and are easily scalable. It means we’ll have multiple web servers behind a Network Load Balancer (NLB). Whenever a request comes, it first goes to the load balancer, which checks all the available web servers and finds the web server which has comparatively less requests to serve, and passes the request to that web server. Continue reading…

Why textbox persists data during postback even if View State set to off

Posted on by

I have seen lots of confusion in various threads, that How and Why a textbox persists data even when View State is set to off. Even I was confused earlier but I tried to discover it and I found the root cause, so sharing it to you all.
For that, first let’s see the page life cycle on postback.

ASP.NET Page Life Cycle

Now lets first discuss about the View State, How View State works?

If View State is on for any control, during LoadViewstate, the View State data that got saved last time , gets populated in the control. And in last, the SaveViewState method of every controls that are part of the control hiearchy, gets called and combined View State of all the controls gets base64 enocoded and saved.

So as we know the page is recreated every time page makes a trip to the server, the data persistence is done with the help of viewstate.

Now here the point that are we are going to discuss, even if we set off the View State of some controls like textbox, checkbox etc.. the data persists during postback.

Let’s discuss it in bit detail, whenever a page is submitted or posted back to server, the entire form data is posted to the server as a collection with the request. The collection is in the form of NamedValue collection and this collection has the mapping with uniqueid of the control and the value of the control. You can read the data from the form collection by using the following code snippet

	 	 
//Reading textbox value from the form collection	 	 
string textboxvalue = Request.Form[textbox1.UniqueID];

ASP.NET uses this primitive to update the control’s value. ASP.NET uses IPostBackDataHandler for the controls that load the data from the form collection.

Actually all the controls which implement IPostbackdatahandler, implement the method LoadPostData and RaisePostDataChangedEvent. But here the key method is LoadPostData, which returns true if the posted value is changed from earlier value and updates it with posted value, else it returns false. Lets see the sample code here

	 	 
public virtual bool LoadPostData(string uniqueId,	 	 
NameValueCollection postedCollection) {	 	 
//Getting the current value of control	 	 
String currentValue = this.Text;	 	 
//Getting the posted value from the form collection	 	 
String postedValue = postedCollection[uniqueId];	 	 
//Checks whether the posted value is changed from the current value, if yes updates it with the posted value and return yes	 	 
if (currentValue == null || !currentValue.Equals(postedValue)) {	 	 
this.Text = postedValue;	 	 
return true;	 	 
}	 	 
//else return false	 	 
return false;	 	 
}

As from the Page Life Cycle, we can see LoadPostData is called after the LoadViewState, whether viewstate is on or not, it gets populated from the posted data. That’s why the data get persisted even if viewstate is set to off for few controls. Following is the complete list of the controls, those implement IPostBackDataHandler.

  • CheckBox
  • CheckBoxList
  • DropDownList
  • HtmlInputCheckBox
  • HtmlInputFile
  • HtmlInputHidden
  • HtmlInputImage
  • HtmlInputRadioButton
  • HtmlInputText
  • HtmlSelect
  • HtmlTextArea
  • ImageButton
  • ListBox
  • RadioButtonList
  • TextBox

I think, this must have helped many of you overcome from this hazzy picture.
Thanks,
Brij

ViewState: Various ways to reduce performance overhead

Posted on by

Introduction
In this Article, I am going to explore the Viewstate. View state is one thing that always I liked to use. It makes our life easier. As we all know that Viewstate is one way of maintaining the states in the web applications.

As we know, a web page is created every time when a page is posted to the server.It means The values that user entered in the webpage is going to be vanished after the poastback or submit. To get rid of this problem, ASP.NET framework provides a way to maintain these values by virtue of Viewstate. When we enable the viewstate of any control, the value is going to be maintained on every postbacks or server roundtrips.

But how these values get maintained? It doesn’t come free.View state uses hidden valriable that resides on the page to store the controls values. It means that if a page have lots of controls with viewstate enabled the page size would become heavy, in several of kilobytes ie it will take longer time to download.And also on every postback all the data is posted to the server i e increasing the network tarffic as well.

As in new era application, we use lots of heavy controls like gridview etc, on our page which makes page size exponetially heavy.It is always recommended to use viewsate judiciously and even some programmers try to to avoid using this cause of performace overhead.

Here , I am going to discuss how we can reduce the performance overhead caused by viewstate.

Problems with viewstate:
n our new era application, we generally have lots of rich and heavy controls on our page and also provide lots of functionality on the page with the help of few latest technology AJAX etc. To accomplish our task we use Viewstate a lot but as we know it doesn’t come free it has a performance overhead.

As we know viewstate is stored on the page in form of hidden variable. Its always advised to use viewstate as less as possible. we have also other ways to reduce the performance overhead. So we have several ways,here I am going to discuss the following ways

* By compressing decompressing the viewstate
* Aanother way to store the view state at some other server say on web server.

ViewState Compression/Decompression
We can compress the viewstate to reduce the pagesize. By compressing the viewstate we can reduce the viewstate size by more than 30%. But here the question arises, where to compress and decompress the viewstate. For that we have to dig into the Page life cycle. As we know, viewstate is used by the ASP.NET to populate the controls. So we should compress the viewstate after all the changes are done in the viewstate and saving it after compression and we have to decompress the viewstate just before it is used by asp.net to load all the controls from viewstate . So lets jump to thepage life cycle and see our we can fit our requirement.
Page Life Cycle
As we can see there are two methods,One SaveViewState that is responsible for collecting the view state information for all of the controls in its control hierarchy in this method and persist it it in __viewstate hiddenform field. The view state is serialized to the hidden form field in the SavePageStateToPersistenceMedium() method during the save view state stage, and is deserialized by the Page class’s LoadPageStateFromPersistenceMedium() method in the load view state stage. So here in these methods we can compress and decompress the viewstate. Lets take a pictorial view.
Flow
So here, we need to override the methods SavePageStateToPersistenceMedium()for compressing the viewstate and SavePageStateToPersistenceMedium() for decompressing the viewstate. Here I am going to use GZip for compression that is provided by the .NET itself.And this is available in th namespace System.IO.Compression….
Complete article has been published on CodeProject. To view Click here