Viewstate Session Cache

Viewstate is used to store Value for the current page only.

 

Session saves Value till the Browser is not closed.

 

Cache  also stored the Value till the Browser exist but when the System resouce goes low then the items in the Cache are dropped directly.

SESSION Variables are stored on the server, can hold any type of data including references, they are similar to global variables in a windows application and use HTTP cookies to store a key with which to locate user’s session variables.

 

VIEWSTATE   Variables are stored in the browser (not as cookies) but in a hidden field in the browser. Also Viewstate can hold only string data or serializable objects.

The viewstate data will be sent twice over the internet (from server to browser, and back), so you will want to keep that as small as possible. Plus, viewstate will only work in postback-scenarios, you will lose it if you redirect or you supply the user with a regular link to some page of yours (but this might be exactly what you want)

 

On the other hand, if you store lots of data for lots of sessions, you need a lot of memory on your server. Plus session-state management itself costs some time on the server.

 

I don’t think it is possible to give a hard formula whether to use viewstate or sessionstate, but if you really don’t need sessions, you might investigate a session-less site (<sessionState mode=”off”/>

in web.config) using viewstate to keep some state.

 

Session: Memory space used to persist user-specific data on the server side.One Session created per user per Session.

ViewState: Hidden form field in ASP.Net form, used to persist page-instance-specific data.

State: A generic term for persistence of data

 

Caching
=======

It’s performance-related. We can store data in local memory through caching for data serving from memory directly for incoming requests.
Benefits are – Fast page rendering, minimization of database hits and minimization of server resources consumption.
Types,
· Page Level Caching (called Output Caching)
· Page Fragment Caching (called Partial-Page Output Caching)
· Programmatic or Data Caching

Output Caching (Page Level Caching)
We can implement Page level, or output caching through Output Cache engine.
It’s a powerful technique, particularly useful for only static pages implementation.
Ex:
<%@OutputCache Duration=”60″ VaryByParam=”none” %>
Note: To solve the request of two pages caching problems follow below specifications,

To solve the problem, We can specify explicitly, like VaryByParam=”PartNo”, or by saying to vary on all GET/POST parameters, like: VaryByParam=”*”.
Partial-Page Output Caching (Page fragment caching)
It’s for specific regions of pages to be cached. We can cache a specific regions of a page like for user control or other listing of inventory list, stock in shopping cart.
<%@ OutputCache Duration=”15″
VaryByControl=”EmpID;DeptID” VaryByParam=”*”%>  
This directive is placed at the top of any User Control (.axcx file).
Data Caching
It’s take advantage of the .NET Runtime cache engine to store any data or objects between responses. So we can store object into a cache but notable point is we should ot store open database connections in the cache.

Cache["foo"] = bar;
To retrieve a value, simply reverse the syntax like this:
bar = Cache["foo"];

note, the cache value should not null prior to doing something with the data.
Ex:
The method GetUserInfo checks to see if the data exists in the cache. If it is present, it is returned from the cache, else, the GetUserInfoFromDatabase method fills the DataSet from the database and then populates the Cache.
public DataSet GetUserInfo()
{   
  string cacheKey = ”UserInfo”;   
  DataSet ds = Cache[cacheKey] as DataSet;   
  if (ds == null)   
 {     
   ds = GetUserInfoFromDatabase();     
   Cache.Insert(cacheKey, ds, null, NoAbsoluteExpiration,       
   TimeSpan.FromHours(15),CacheItemPriority.High, null);   
}      
return ds;
}  

DataSet GetUserInfoFromDatabase()
{
// Usual code to populate a data set from thedatabase. This data set
// object is then returned.
}

Session State Management
=====================

Session State Management

On behalf of clients it’s keep maintaining state for track of items. It’s very much useful in online shopping cart.

InProc:
State is maintained within the managed memory of the Asp.Net process. So runs in same process area. Speed is advantage but no stability.

OutProc :
State is maintained and managed by external resource like stateserver or SQL Server.
It works outside the clients memory. We have to compromise a bit on speed but stability is there.

Note :
The storage, fast and robustness is,
Inproc :
Kept as live object in web server(aspnet_wp.exe). ie. Stored in memory space of appdomain.
Fast, consume memory on webserver.
Session state will loss on recycle of worker process(aspnet_wp.exe) or restart of appdomain.
Because session state is stored in memory space of an appdomain.
Stateserver :
Session serialized and stored in memory(aspnet_state.exe). State server can run on another machine.
15% Slowerthan InProc while stroing basic data types like string,integer,etc. and serialization/deserialization too affect performance.
Session state won’t loss because webform store session on central server.

SQL Server :
Session serialized and stored in sql server
25% Slowerthan InProc while stroing basic data types like string,integer,etc. and serialization/deserialization too affect performance.
Similar to stateserver but Sqlserverprocess.