Session State - Which Mode in which Scenario.

Session State – Which Mode in which Scenario… - Factors to choose between speed, reliability, security and scalability.

 

M.M.Imp:-

 

a)     

 

Remember never to use a Response.Redirect or Server.Transfer method call after you set the Session in the login page of your application.  

Both these methods call the Response.End method internally.  The Session ID would be lost as the Response.End method stops execution of the page.  

Use the FormsAuthentication.RedirectFromLoginPage method instead. Alternatively, you can use the following overloaded version of the Response.Redirect method.

 

Response.Redirect("~/menu.aspx", false)

 

This would not abort the current thread and would prevent the Session ID from being lost.

 

b).

Note that the Session state is available only after the HttpApplication.AcquireRequestState event is called.  The Session_End event is supported only in the InProc mode and is fired internally by the Web Server, based on an internal timer. Thus, there is no HttpRequest that is associated when that happens.  

This is why the methods Response.Redirect or Server.Transfer do not work in the Session_End event.  

The Session_OnEnd event is called when we make a call to the Session.Abandon method or when the Session times out.

------------------------------------------------------------------------------------

 

 ‘In Proc’:

 

[Definition]

·         Provides the fastest access to session state.

·         No serialization or marshaling costs involved because state is maintained within  the managed memory of the ASP.NET process.

·         When the process recycles, the state data is lost, although you can disable process recycling in IIS 6 if process recycling affects your application.

·         The in-process store limits application scalability because you cannot use it in conjunction with multiple worker processes; for example, it prevents Web farm or Web garden deployment.

·         In case of web-garden do not use InProc session state mode. If you do, data loss can occur if different requests for the same session are served by different worker processes.

·         It is the fastest of all the three modes.

·         The Session_End event is supported only in the InProc mode and is fired internally by the Web Server, based on an internal timer.

 

[When to use]

·         When you have a single Web server,

·         When you want optimum Session State Performance, and

·         When you have a reasonable and limited number of concurrent sessions.

·         In a production environment, the InProc mode of Session State storage is not feasible.  When we have to go for WebFarms, the OutProc mode is the best; especially when the traffic is heavy on the site.

------------------------------------------------------------------------------------

 

‘State Server’:

 

[Definition]

 

·         Can be installed on your local Web server or on a remote server that is accessible by all Web servers in a Web farm.

·         StateServer mode stores session state in a process, referred to as the ASP.NET state service, that is separate from the ASP.NET worker process or IIS application pool. Using this mode 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.

·         This approach scales well, but performance is reduced in comparison to the in-process provider because of the additional serialization and marshaling that is required to transfer the state to and from the state store.

·         Session state is serialized and stored in memory in a separate process that is managed by the aspnet_state.exe file.

·         If your remote state service and your Web server are separated by a firewall, then you need to open a port. The default port is port 42424. You can change the port in the following registry key:

o    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters.

·         The new out-of-process model allows all servers in the farm to share a session state process. You can implement this by changing the ASP.NET configuration to point to a common server. 

 

 

[When to use]

 

·         When you have a single Web server and your sessions are expensive to rebuild and when you require durability in the event of an ASP.NET restart.

·         When you have a Web Farm.

·         Use a remote state service, if you do not have a SQL Server database.

 

------------------------------------------------------------------------------------

 

‘SQL Server’:

 

[Definition]

 

·         Provides a highly scalable and easily available solution.

·         Well-suited to large amounts of session state.

·         The serialization and marshalling costs are the same as the costs for the session state service, although overall performance is slightly lower.

·         SQL Server is more secure than the InProc or the State server modes of Session State storages as the data can be secured easily by configuring the SQL Server security.

·         SQL Server mode of storage is suited when we need to secure the Session data or when we require scalability and reliability, but it takes more time to store and retrieve data to and from the database table.

·         SQL Server provides Clustering For Failover, although this is not supported in the default configuration for session state. To enable clustering for failover, you have to apply configuration changes, and the session data must be stored in a non temporary table.

 

[When to use]

 

·         When you have a single Web server when reliability is your primary concern.

·         When you have a Web Farm.

·         Use SQL Server for enterprise applications or high volume Web applications.

·         Well-suited to large amounts of session state.

 

 

[Configuring SQL Server]

 

 

 

 

 

Thanks & Regards,

Arun Manglick

SMTS || Microsoft Technology Practice || Bridgestone - Tyre Link || Persistent Systems || 3023-6258

 

DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails.