Which one is better, InProc or SQL Server, for Session State mode in asp.net?

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?

You can use Session in 3 ways. Each one has advantages and disadvantages

In-Proc :

- Inproc session is faster.
- You can add objects withouth serialization
- But limited to one server, if your application will run on more than
one server. This wont work for you
- If something happens Application Pool you will lose all you session information

Session State :

- Will run as windows service
- If your app will run accross multiple server, this will help
- Objects added to Session needs to be serialized

Sql Server:

- Uses sql server, but there are Oracle implementation as well
- Slower than State Server
- Much more reliable

Check out this question also :

[To see links please register here]

Better in terms of what?
--

* **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.

Cookieless session
--

> 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
--
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.

**InProc Session State**

InProc session mode indicates that session state is stored locally, means that with InProc session state mode is
store objects in the AppDomain of the Web application.Because of this the session state is lost when IIS (Internet Information System) restarts.
Generally, the AppDomain is restarted based on several factors like memoryLimit attribute
settings in the section of the configuration file, modifiying Global.asax or the Web.config file etc.

We can use StateServer or SqlServer session state mode for overcome these issues and here session state is not stored in the AppDomain of the Web application.

**OutProc Session State**

In OutProc Session ,Sessin State is stored In the StateServer and SqlServer modes not in the AppDomain of the Web application.

**StateServer:** it uses a stand-alone Microsoft Windows service to store session variable, so this service
is independent of IIS, it can run on a separate server.
You can use this mode for a load-balancing solution because multiple Web servers can share session variables.
Although session variables are not lost if you restart IIS, performance is impacted when you cross process boundaries.

**SqlServer:** SqlServer mode also enables you to utilize a state store that is located out of the IIS process and that can be
located on the local computer or a remote server. For persistence of session information, you can use SqlServer mode
SqlServer mode is similar to out-of-process mode, except that the session data is maintained in a SQL Server.