Getting Started with Adobe After Effects - Part 6: Motion Blur


Upload Image Close it
Select File

Browse by Tags · View All
BRH 48
#DOTNET 34
#ASP.NET 29
jQuery 22
ASP.NET 20
.NET 20
WPF 9
jquery interview questions 9
jquery faq 8
ASP.NET4 8

Archive · View All
February 2011 10
September 2011 4
August 2011 4
July 2011 4
May 2011 4
April 2011 4
March 2011 4
October 2011 4
June 2011 4
January 2011 4

ASP.NET Session vs ViewState

Apr 13 2011 5:52AM by Hima   

The following is question that is asked by one of the Community Member from Beyond Relational Website to my personal ID.

“I have one doubt in sessions.  Sessions are using in the website that sessions variables are storing in server. Suppose at a time if ten users send the request to server, 10 sessions variables are storing in the server are not. Suppose ten session variables are created lot memory required in server. In the session replace using the view state. I want to get clear difference between sessions and view state”

Yes It is. For each user each session gets created and stores separately. If there are 100 users, accessing same data and you are creating session for that, 100 sessions will be created even though you have same data. 100 different session IDs are stored in the server for the requests and session is tracked based on session ID. Yes if you have number users accessing and storing large data in sessions then page load will be slow definitely.

When every client is send request to the server store Session is accessible at the client side in the form of cookies. So Every time client hits the server in the user machine does it creates cookies each time?

Actually cookies are 2 types.

    1. In Memory Cookie
    2. Persistent Cookie

If the Persistent cookie gets created for the request, then Every time client hits the server in the user machine does it creates cookie. This cookie is persistent until user deletes browser cookies.

These are typical ASP.NET beginner question, but I am not sure how many web developers today use View-State and Session State efficiently and effectively. It is important to understand the concepts and equally important to utilize them where and when required. Here are some best and important practices to be followed considering performance of the web applications regarding view state and session state.


Can I replace session using the viewstate.? Session vs ViewState

No. Both are different concepts that cannot be replaced one with another.  Session is persistent across single browser, whereas ViewState is for single page. ViewState is stored on browser or client means in webpage, session is on server.
Whenever you are using the sessions clearing sessions are important. Remember that closing the browser does not get session to clear. You need to call

  • Session.Clear() - clears the session.
  • Session.Abandon() - destroys the session completely .

It is a best practice to clear the session while you are no longer need them or their purpose is solved.

When to use What?
If you need to access a variable in same page, then you can go for view state. 

For example

  • If you are accessing variables on the same page (to get data) under post back use ViewState.
  • If the data you store in the ViewState is not large enough to cause performance headaches, go ahead with Viewstate.
    For accessing variables across any other (throughout) pages you can use session.

For example
Suppose you have requirement like to open a child window through client script and the child window requires some information related to parent page. In such case, You can store the information in session before loading the first page and clear the session when the child window gets loaded, obtain the information from session for parent window.

Clearing the session is very important, if data is not needed any more in other pages.

If you have ViewState of your page is large, use HTTP Compression.

We do not really need to store the ViewState for Label. In most cases we can avoid ViewState for it for a HyperLink and even Images and buttons too.

At worst turn the ViewState off for each control and see if your page renders fast or not.
The larger our page is, the longer it takes to render on the client side browser.  Smaller page size is always better. If there is data in the control that will be needed when the Form is posted, then only enableViewstate, otherwise set it to false.

If the session mode is inproc then session gets destroys when application Pools memory is over and it gets recycled. Try to get data from data base with best practices instead of using Sessions for same database calls across pages. Having ViewState will also degrades SEO as the google will give less indexing for the page that has ViewState comparing the page with the same content but no ViewState. That is why MVC3 is most popular than asp.net web forms. No ViewState, No Page load for ASP.NET MVC projects.

ASP.NET4 gives us more control on Viewstate by ViewStateMode property, to disable ViewStateMode at page level and enable ViewStateMode at control level.

  • Do not rely heavily on session variables. This can lead to many "object not set to an instance of an object" errors, which can be terrible to debug. No reliability.
  • Never replace viewstate with session
  • Don't store datasets in a session.
  • Don’t store GridView data in a session.

Tags: BRH, ASP.NET, session, viewstate,


Hima
31 · 6% · 1776
0
Liked
 
0
Lifesaver
 
0
Refreshed
 
0
Learned
 
0
Incorrect



Submit

2  Comments  

  • Read your post on Session vs ViewState. it's awesome.its simple and understandable......

    Waiting for more post..

    Thanks Rajneesh.

    commented on Apr 13 2011 8:04AM
    razneesh11
    1997 · 0% · 9
  • hello hima,

    Nice post one more addition to you post that you can store viewstate in session. Here is the link for that.

    http://jalpesh.blogspot.com/2009/07/store-page-viewstate-in-session-with.html.

    So you can have less viewstate in page source

    Regards, Jalpesh

    commented on Apr 13 2011 3:24PM
    Jalpesh
    15 · 11% · 3548

Your Comment


Sign Up or Login to post a comment.

    Copyright © Rivera Informatic Private Ltd Contact us      Privacy Policy      Terms of use      Report Abuse      Advertising      [ZULU1097]