1. Session
Session management is a very strong technique to maintain state. Generally, the session is used to store the user's information and/or uniquely identify a user (or say browser). The server maintains the state of user information by using a session ID. When a user makes a request without a session ID, ASP.NET creates a session ID and sends it with every request and response to the same user.
Label2.Text = Session["Count"].ToString(); //Get Value from the Sesion
Session Events in ASP.NET
To manage a session, ASP.NET provides two events: session_start and session_end that is written in a special file called Global.asax in the root directory of the project.
Session_Start: The Session_startevent is raised every time a new user makes a request without a session ID, i.e. the new browser accesses the application, then a session_start event raised. Let's see the Global.asax file.
Eg.void Session_Start(object sender, EventArgs e){
Session["Count"] = 0; // Code that runs when a new session is started
}
Session_End: The Session_Endevent is raised when the session ends either because of a time out expiry or explicitly by using Session.Abandon(). The Session_Endevent is raised only in the case of Inprocmode, not in the state server and SQL Server modes.
There are four session storage mechanisms provided by ASP.NET:
1.In Proc mode
2.State Server mode
3.SQL Server mode
4.Custom mode
1. In Process mode: In proc mode is the default mode provided by ASP.NET. In this mode, session values are stored in the web server's memory (in IIS). If there are more than one IIS servers then session values are stored in each server separately on which request has been made. Since the session values are stored in the server, whenever the server is restarted the session values will be lost.
Eg.<configuration>
<sessionstatemode="InProc" cookieless="false" timeout="10"
stateConnectionString=" tcpip=127.0.0.1:80808"
sqlConnectionString="Data Source=.\SqlDataSource; User ID=userid; Password=password"/>
</configuration>
2. In State Server mode: This mode could store session in the web server but out of the application pool. But usually, if this mode is used there will be a separate server for storing sessions, i.e., stateServer. The benefit is that when IIS restarts the session is available. It stores session in a separate Windows service. For State server session mode, we have to configure it explicitly in the web config file and start the aspnet_state service
Eg.<configuration><sessionstatemode="stateserver" cookieless="false"
timeout="10" stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="Data Source=.\SqlDataSource; User ID=userid; Password=password"/></configuration>
3. In SQL Server mode: Session is stored in a SQL Server database. This kind of session mode is also separate from IIS, i.e., the session is available even after restarting the IIS server. This mode is highly secure and reliable but also has a disadvantage that there is overhead from serialization and deserialization of session data. This mode should be used when reliability is more important than performance.
Eg.<configuration>
<sessionstatemode="sqlserver"cookieless="false" timeout="10"
stateConnectionString="tcpip=127.0.0.1:4 2424"
sqlConnectionString="Data Source=.\SqlDataSource; User ID=userid; Password=password"/>
</configuration>
4. Custom Session mode: Generally we should prefer in proc state server mode or SQL Server mode but if you need to store session data using other than these techniques then ASP.NET provides a custom session mode. This way we have to maintain everything customized even generating session ID, data store, and also security.
2.Application
Application state is a server side state management technique. The data stored in the application state is common for all users of that particular ASP.NET application and can be accessed anywhere in the application. It is also called application level state management. Data stored in the application should be of small size.
Eg. Application["Count"] = Convert.ToInt32(Application["Count"]) + 1; //Set Value to The Application Object
Label1.Text = Application["Count"].ToString(); //Get Value from the Application Object
Application events in ASP.NET
There are three types of events in ASP.NET. The application event is written in a special file called Global.asax. This file is not created by default; it is created explicitly by the developer in the root directory. An application can create more than one Global.asax file but only the root one is read by ASP.NET.
Application_start: The Application_Start event is raised when an app domain starts. When the first request is raised to an application then the Application_Start event is raised. Let's see the Global.asax file.
Eg.void Application_Start(object sender, EventArgs e)
{
Application["Count"] = 0;
}
Application_Error: It is raised when an unhandled exception occurs, and we can manage the exception in this event.
Application_End: The Application_End event is raised just before an application domain ends because of any reason may IIS server restarting or making some changes in an application cycle.
Application state data is generally maintained by writing handlers for the events:
1. Application_Start
2. Application_End
3. Application_Error
4. Session_Start
5. Session_End
Eg.Void Application_Start(object sender, EventArgs e)
{
Application["startMessage"] = "The application has started.";
}
Void Application_End(object sender, EventArgs e)
{
Application["endtMessage"] = "The application has ended.";
}
0 comments
Post a Comment