Menu
I am developing an ASP.NET website. I want to know which one is better in session state mode: InProc or SQL Server? I need to hear about your experiences on this issue.
Another question is about cookieless attribute. Is there any security hole in my site if I set it to true? In all the samples I saw in MSDN site, this attribute was set to false.
And the last question is about Timeout attribute. Does this attribute effect my sessions lifetime when I set it to InProc mode?
202
The InProc Session State Mode stores session data in a memory object in the application worker process (aspnet_wp.exe) in the application domain. It is usually the fastest, but more session data means more memory is used on the web server, and that can affect performance.
The session state is stored in the ASPState database. The advantage of this method is that the data is persisted even if you restart the SQL server. Custom storage: Both the session state data and the stored procedures are stored in a custom database. The database name must be specified in the configuration file.
InProc session data will be lost if we restart the server, or if the application domain is recycled. It is also not suitable for Web Farm and Web Garden scenarios. Now we will have a look at the other options available to overcome these problems. First is the StateServer mode.
web configuration section. You can also configure session state by using the EnableSessionState value in the @ Page directive. The sessionState element enables you to specify the following options: The mode in which the session will store data.
InProc session is much much faster, has less requirements (serialization), but unusable when you're running your application on several web servers;
Sql session is much slower, has object serialization requirements, but can be shared between several web servers;
That's the main difference between them that developers should mostly care about.
You should ask a separate question regarding this, because it's a completely unrelated question to previous one.
If you turn off cookie session ID handling you will be able to see Session ID. But so can you if you check cookies. The number is there.
And Session cookie expiration is set to browser session so it's practically the same in terms of persistence.
Sessions can be hijacked if you know other party's Session ID. It's easier of course if you use cookieless sessions because all you have to do is to change URL...
And there's another thing with copying URLs and sharing/saving (Favourites). I suppose I don't have to explain the problem.
Cookieless sessions are false by default because vast majority of browsers support cookies. You should only turn it on when you know your clients won't have cookies.
Session timeout is always related to session expiration regardless of session type. But you have to be aware that SQL session state may not obey this setting when you use SQL Express editions because you need SQL Server Agent service to discard expired sessions. You can mitigate this problem by writing you own Windows Service that discards expired sessions.
71
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
