33

Recommended by the ASP.NET team to use cache instead of session, we stopped using session from working with the WebForm model the last few years. So we normally have the session turned off in the web.config

<sessionState mode="Off" />

But, now when I'm testing out a ASP.NET MVC application with this setting it throws an error in class SessionStateTempDataProvider inside the mvc framework, it asked me to turn on session state, I did and it worked. Looking at the source it uses session:

// line 20 in SessionStateTempDataProvider.cs
Dictionary<string, object> tempDataDictionary = 
httpContext.Session[TempDataSessionStateKey] as Dictionary<string, object>;

So, why would they use session here? What am I missing?

========================================================

Edit Sorry didn't mean for this post to debate on session vs. cache, but rather in the context of the ASP.NET MVC, I was just wondering why session is used here. In this blog post also Scott Watermasysk mentioned that turning off session is a good practice, so I'm just wondering why I have to turn it on to use MVC from here on.

edymtt
  • 1,778
  • 1
  • 21
  • 37
Ray
  • 12,101
  • 27
  • 95
  • 137
  • Could you provide a link to where they say "use cache instead of sessions" , cause, they are not really meant for the same thing? – Filip Ekberg Dec 22 '08 at 19:44
  • If I remember correctly I read it in the September 2005 issue of the MSDN magazine. Maybe I should word it better, but we just don't use session altogether. – Ray Dec 22 '08 at 19:48
  • He said: "Tip: Disable session state when not in use.", it's rare that sessions arent used in an authenticated area. – Filip Ekberg Dec 22 '08 at 20:04
  • Provided Scott link does not work anymore. – Shane Courtrille Feb 22 '11 at 20:45
  • As an aside, the article about session state found in the September 2005 issue of MSDN magazine can be read [here](http://msdn.microsoft.com/en-us/magazine/cc163730.aspx) -- please note that it refers to a prerelease version of ASP.NET 2.0 – edymtt Dec 13 '12 at 18:51

4 Answers4

33

Session is used for the TempData store. TempData is a highly limited form of session state which will last only until the next request from a certain user. (Edit In MVC 2+, it lasts until it is next read.) The purpose of TempData is to store data, then do a redirect, and have the stored data be available to the action to which you just redirected.

Using Session for the TempData store means that any distributed caching system which already handles Session will work for TempData. Avoiding using Session directly when TempData will do has a couple of advantages. One is that you don't have to clean up the Session yourself; TempData will "expire" on its own.

Craig Stuntz
  • 125,891
  • 12
  • 252
  • 273
  • 3
    How does this work in a round robin web farm configuration? Is there a way to turn off Session State/TempData in MVC? – Chuck Conway Apr 30 '09 at 20:03
  • 2
    It works the same way as session always works on a server farm. This is documented on MSDN. The best way is to use a distributed cache, but you can also use "sticky sessions." Regarding turning off session, again, it's just like any other ASP.NET application. See MSDN. Then just don't use TempData. That said, doing so is like curing acne via beheading. – Craig Stuntz Apr 30 '09 at 21:02
  • 10
    Session state can be disabled, by disabling in the web.config and implementing the ITempDataProvider interface. – Chuck Conway May 19 '09 at 01:09
  • @Craig Damn you. Just wrote a question and found here an answer when checked once more for duplicates. Wasted ~15 minutes... xD – Arnis Lapsa Jun 27 '09 at 08:15
  • Santose: In MVC 1, on the next request. In MVC 2 beta +, when it is next read. – Craig Stuntz Nov 19 '09 at 12:45
  • Craig, you might want to edit your answer for MVC 2+ (as you have in the comment above). Folks read your answer and skip this part – RickAndMSFT Oct 07 '11 at 01:16
13

Recommended by the ASP.NET team to use cache instead of session

@ray247, could you provide a reference for this? Session and Cache are different by nature and should be used depending on application requirements. For example storing user specific data into the cache could lead to undesired behavior. Of course if you really want to avoid using session you could provide your own implementation of the ITempDataProvider interface.

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
  • btw, why would stoing user specific data into cache could lead to undesired behavior? If you got the cache key correctly for each user, I don't see how it's a problem. – Ray Dec 22 '08 at 20:03
  • 4
    Because the cache is by definition volatile. There are some situations outside your control such as memory pressure in which the cache could get invalidated and thus loosing all session data. – Darin Dimitrov Dec 22 '08 at 20:23
  • 1
    "By default, ASP.NET applications store the session state in the memory of the worker process, specifically in a private slot of the Cache object." - MSDN (http://msdn.microsoft.com/en-us/library/aa479041.aspx) – Chris Shouts Jan 11 '10 at 21:15
6

Hmm... May be you've read about persisting of the heavy objects or relatively rarely accessed objects - it's definitely better to put them into cache, but for light objects or for data that is required at every request there is no better technique than put them into Session.

Sessions are not evil if you are using them correctly.

maxnk
  • 5,755
  • 2
  • 27
  • 20
  • 1
    Know this is an old question, but this answer (and in a lesser degree all the others too) ignores the fact that the OP was using a **WebFarm** infrastructure, which implies in using SQL Server (which is quite slow for that task) or a dedicated, network shared windows service (which is a pain in the a**) for keeping that session - so caching would probably be a better choice indeed. – rsenna Dec 13 '10 at 18:26
3

Just an additional thought. TempData has its own purpose and MS knew there will be different school of thoughts with respect to TempData persistent mechanism. So, by default they made the persistent store to be SessionState. But the design is still very flexible. Based on the needs of the project and the governance that guides it you can create your own tempdata provider to suit specific requirements.

Here are some pointers to the resources TempData

Here are some additional improvements in TempData implementation TempData Improvements

Here's an alternative implementation using MS Velocity Distributed Caching. Velocity TempData Provider

rajesh pillai
  • 8,102
  • 7
  • 43
  • 60