Sessions In Aspnet
As you know HTTP is state less protocol meaning is server doesn’t maintain the state of
Page once it is rendered at client side. It works completely in disconnected manner.
All server side scripting technologies like Asp.net, JSP, PHP and perl outputs browser understandable
output (HTML). Browser is HTML parser once it sees html tag like <B>name</B> to bolds the text written inside that tag.
Storage mechanism and State management.
1. Without maintaining state.
2. With maintaining State.
1. without maintaining state.
Assume we had developed website which has features like authentication and authorization.
How it will work without maintaining state? Let’s see.
We would have a login page where user can input his/her credentials and post it to server.
Server will authenticate the request and give appropriate response as per the request.
Next time when user requests something from server it should know that user is already authenticated.
Isn’t it? But we haven’t maintained the state of user then how could server know that whether user
is already authenticated or not? In this scenario user has to re-login again. As its HTTP stateless request
and server doesn’t maintain the state of page once it gets rendered to client. To overcome such situations technology came up with state storing mechanisms
like Hidden Fields and Cookies.
Let’s look at how it works by maintaining state.
2. with maintaining state.
Consider the same scenario but this time once user log-in, server will send authentication cookie
along with response so next time request came to server it will look for authentication cookie
in request. If Authentication cookie exists server will skip authentication process and it will authorize
the user to download or view stuff from server.
Asp.net Technology uses below data storing mechanisms.
1. Session object.
3. Application object
cookies are domain specific. Cookie enabled browsers can store domain specific cookies
at client side. When user request the server browser sends cookies along with the request.
At server side we can get cookie information from request.
It is advisable not to store big data in cookie as it will lower the performance of your web.
Look at Session Object explained below.
ViewState is hidden field. Difference between cookie and hidden field is cookie gets stored at client’s hard drive
where hidden filed information lies inside the html body.
1. Session Object:
As we can’t deliver large amount of data to client by using cookie objects to avoid bandwidth consumption.
Asp.net can store the data inside session object.
In Proc session and out Proc session:
If web application requests are served by single asp.net worker process and single machine
then we can use In proc session storing mechanism. Here session objects get stored inside
worker process context like this.
Reference ID = uxab12, Data= Actual big Data
Reference ID gets delivered to browser in terms of cookies.
If cookies are not enabled the session reference ID gets appended to URL like this
Next time when user sends a request the browser sends cookies to server and asp.net
finds the cookie Id uxab12 which re-initiate the user session if session expiry time not reached.
WP also updates the date time stamp of session.
In this scenario if application pool gets recycled due to proactive or reactive process model,
the value stored inside session get lost because of in-proc session storing mechanism.
During recycling of application pool new instance of worker process get created and as soon as
old requests get served by old worker process it kills old worker processes. All new requests get served
by new instance of worker process. To overcome situation of loosing session worker process has to use
shared memory space for sessions. It can be achieved by Out- proc session storing mechanism using
MS SQL server or State Server or custom session storing mechanism.
You can add many worker processes into application pool to serve the request. In this case you need to use out Proc session mechanism.
2. Cache Object
Cache object scope is global to entire web application. The data get stored at server side memory of
worker process. Cache object can be expired user defined cache expiry time.
In scenarios where application pool was served by many worker processes, each worker process
gets its own copy of cache which leads high consumption of memory due to duplicate copy of cache object at each worker process.
3. Application object
Application object scope is also global to entire web application like cache. Data stored inside application object remains available for use till life of web application.
As soon as application pool gets recycled data stored in application object gets destroyed. We can’t set expiry time like how we set it for cache object.