Server side State Management : Session Objects
Storing the data using the client side management is some times not practical when we need to store more amount of data and that to for each user who is logging, for that in asp.net provided use session objects to store state per user. Every time we create new instance of web browser new session object is getting created, we can store data in session.
Default timeout for session objects are 20 mins if we are inactive on the browser.Session objects can be implemented with the help of Cookies or without Cookies ( CookieLess ) . By default, ASP.NET uses a cookie containing a unique and random ID that it uses to look up the Session object in the ASP.NET server process. If different users are using your application, each user session has a different session state. If a user leaves application and then returns later after the session timeout period, session state information is lost and a new session is created for the user. Session state is stored in the Session
key/value dictionary like HashTable.
ASP.NET provides mechanisms for storing information for a single user session or across multiple sessions. This is done using the HttpSessionState.Asp.net Session Objects can be maintained in 3 ways In-process ( InProc) , Out of Process ( State Server ) , SqlServer
InProc ( InProcess) – Stores session state in memory on the Web server as live objetcs. This is the default, and it offers Fastest performance than using the StateServer or SqlServer.
InProc is fine for simple applications, but robust applications that use multiple Web servers or must persist session data between application restarts should use State Server or SQLServer.But if there is more session data, the more memory is consumed on the web server, and that can affect performance.
Configuration in Web.config for “inproc”
sqlconnectionstring=”datasource=127.0.0.1;user id=userid;password=password” server=”127.0.0.1″
StateServer : StateServer Stores session state in a service called the ASP.NET State Service. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm. ASP.NET State Service is included with any computer set up to run ASP.NET Web applications; however, the service is set up to start manually by default. Therefore, when configuring the ASP.NET State Service, you must set the startup type to Automatic.
Configuration in Web.config for “StateServer”
SQLServer: SQLServer Stores session state in a SQL Server database. This ensures that session state is preserved if the Web application is restarted and also makes session state
available to multiple Web servers in a Web farm. On the same hardware, the ASP.NET State Service outperforms SQLServer. However, a SQL Server database offers more robust data integrity and reporting capabilities.
Configuration in Web.config for “SqlServer”
sqlconnectionstring=”data source=YourSQLServer;user id=userid;password=password”
This method has several drawbacks:
*) Type Safety: Session contains objects, so you need to cast.
*) Null reference: You must check, it might be null. ( Null Reference error while inserting in db)
*)Variable name: don’t use hard coded strings.
You can use the session-state stores that are included with ASP.NET, or you can implement your own session-state store provider. You might create a custom session-state store provider for the following reasons:
* You need to store session-state information in a data source other than SQL
Server, such as a FoxPro database or an Oracle database.
* You need to manage session-state information using a database schema that is different from the database schema used by the providers that ship with the .NET Framework. An example of this would be shopping cart data that is stored with a predefined schema in your existing SQL Server database.
Advantages of using session state are:
* Simple implementation The session-state facility is easy to use, familiar to ASP developers, and consistent with other .NET Framework classes.
* Session-specific events Session management events can be raised and used by your application.
* Data persistence Data placed in session-state variables can be preserved through Internet Information Services (IIS) restarts and worker-process restarts without losing session data because the data is stored in another process space. Additionally, session-state data can be persisted across multiple processes, such as in a Web farm or a Web garden.
* Platform scalability Session state can be used in both multi-computer and multi-process configurations, therefore optimizing scalability scenarios.
* Cookieless support Session state works with browsers that do not support HTTP cookies, although session state is most commonly used with cookies to provide user identification facilities to a Web application. Using session state without cookies, however, requires that the session identifier be placed in the query string, which is subject to the security issues stated in the query string section of this topic. For more information about using session state without cookies, see Configuring ASP.NET Applications.
* Extensibility You can customize and extend session state by writing your own session-state provider. Session state data can then be stored in a custom data format in a variety of data storage mechanisms, such as a database, an XML file, or even to a Web service. For more information, see Implementing a Session-State Store Provider.
Disadvantage of using session state are:
* Performance considerations Session-state variables stay in memory until they are either removed or replaced, and therefore can degrade server performance. Session-state variables that contain blocks of information, such as large datasets, can adversely affect Web-server performance as server load increases.