0

In my web application I test for a condition on one page and want to retain the results of the test for a specified duration (such as 5 minutes). I can do this with a cookie, of course, but just in case a user has disabled cookies, I'm thinking a custom server varible might do the trick. I've heard about this, but I haven't been able to find out to do it.

Alternatively, maybe a session variable might be better? There's no inherent way to expire these, right? How long would such a variable survive before IIS tosses it?

tshepang
  • 12,111
  • 21
  • 91
  • 136
Cyberherbalist
  • 12,061
  • 17
  • 83
  • 121
  • 1
    Just checking, this is per user session right? If they've disabled cookies, you don't be able to track session... Unless you have `cookieless=true`? – Dominic Zukiewicz Feb 13 '14 at 21:35
  • session variable exists while session exists. By default it's 20 minutes from last request. You can also use Cache. You can add item to cache with Expiration time 5 minutes, and then it will be removed. But you need to maintain it per user, as Cache is the same for all of them – Sergey Litvinov Feb 13 '14 at 21:38

2 Answers2

2

Asp.Net has session state. Each Asp.Net Page has a Session property. You can also access it via HttpContext.Current.Session, though there is a subtle difference that won't matter until it bites you (which see my answer to the question, Difference between Session and HttpContext.Current.Session.

The default session state configuration is in-memory. That means that if your web site is served up from something like an F5 Networks Big IP (load balancer) cluster, unless the load balancer is set up to be 'sticky' (meaning that once assigned to a machine in the cluster, you'll always hit that machine unless it goes down or is otherwise removed from the cluster).

If your clustered web site doesn't have sticky sessions, your session state will vanish when your request hits a different machine...and then reappear when another request hits the original machine. You can guess how much fun that can be.

There is built-in support for SQL Server session that you can enable in your web.config. Once set up that way, you're using SQL Server as the backing store for session state. That solves the server farm issue noted above, but does so at the expense of hitting a SQL Server each and every time a session state value is accessed. That slows down access considerable, especially if the session size large. Oddly, executing a SQL query and shoving a 500kb session blog across the network every time you access a session state setting can negatively impact performance. Who knew? [Don't ask how we found that out].

There are other solutions to the problem: ScaleOut's products come to mind (e.g., ScaleOut SessionServer).

Or you can roll your own session state provider using something like an AppFabric cache.

Another "feature" of using SQL Server sessions state is that anything going into Session must be ISerializable.

Community
  • 1
  • 1
Nicholas Carey
  • 71,308
  • 16
  • 93
  • 135
1

You can't set a server variable; instead, using Session, which is tied to the current user, is the best approach for user-based data. For application-based data, you can consider cache. So assuming the former, do:

Session["Key"] = MyValue

Note that session lasts 20 minutes; if you have to have exactly 5 minutes, you can use cache, which you can explicitly expire at 5 minutes:

Cache.Add(CurrentUserID.ToString() + "Key", "Value", .. TimeSpan.FromMinutes(5));

You can use the ID of the current user to make the cache value specific to a user, or use cookies, but set HttpOnly=True on the cookie object. An HTTPOnly cookie is only on the server and never accessible on the client, as such:

varcookie = New HttpCookie("Key", Value);
cookie.Expires = ..;
cookie.HttpOnly = true;
Brian Mains
  • 50,520
  • 35
  • 148
  • 257