Windows Azure Architecture Guide – Part 2 – Managing sessions

  • Article

Session management is an important consideration for applications deployed to Windows Azure. In essence, the guidelines for “web farms” are all 100% applicable for Windows Azure.

Some (most?) people rely on “in memory” session state and then tweak their network to have “sticky” sessions: users will be directed always to the same instance. This doesn’t work in Windows Azure because you can’t “tweak the network”. In Windows Azure, all instances of an app are equals and all get the same share of the load, and you clients will end up in different servers. So, what do you do?

Most people that “don’t tweak the network”, use one of the providers included in ASP.NET, like the SqlSessionStateStore class. In Part 1 of the guide, the application uses this server side session store. The only difference is that we used one of the providers that are part of the Windows Azure SDK samples and uses Table & blob storage for persistence.

Note: the Windows Azure SDK provider additional samples are quite old and haven’t been updated in a while. We used them “as-is” and did minimal changes and bug fixes. At this point however, I would encourage folks to consider building their own, o do some heavy testing on them. Of course the SqlSessionStateStore object would work well with SQL Azure.

For TailSpin, we decided to use a different approach and get rid of server side session completely. The trick is simple (and old). We will just pass back and forth an opaque serialized object that represents the user session. Instead of cookies, we will use a hidden form in the pages. In essence, this is exactly what other frameworks do (like WIF, that uses cookies instead). Using client-side session means that we don’t need any special infrastructure on the server.

Since we are using MVC 2.0 for this sample, we are taking advantage of features in the “futures” library that make implementing this much easier (see here).

In the controller you’ll see the [Deserialize] attribute:

image

And then in the view:

image

Of course there are tradeoffs and not every application would benefit from this approach. Some of the forces you will have to consider:

  1. It increases the bandwidth use.
  2. It might not be suitable for apps that require large objects in sessions.
  3. You might end up paying more (remember in Windows Azure you pay for in/out bandwidth). There might be a breakpoint in the cost of storage vs. cost of bandwidth.
  4. In our current implementation, the app has to deal with this explicitly (as opposed to being a “cross-cutting concern”)
  5. It doesn’t require any server side config/setup.