I'm looking for the current (2013) recommendation for Session State management on Windows Azure. There is a number of articles I found on the web but they reference older mythologies. I thought I found the latest method in this Microsoft article but when I went got to step 2 that says to setup Caching in Windows Azure Management Portal, it wasn't an option. I'm assume that there is a newer methodology that I just didn't see.
Here are my requirements:
Basically I'm looking for the equivalent to out-of-process storage providers such as Session State Service or SQL Session State option that are used in non-Azure ASP.NET deployments.
One other concern I have to using the Cache is what are the scenarios when sessions are deleted? Normally I think of Cache as not guaranteed because of expiration and making room for newer cache items. I want to make sure sessions don't start to disappear because they are in Cache.
UPDATES:
You are on the right track to use caching for shared state. Where caching gets confusing and temporal (as you have seen by different articles on different dates) is that what used to be called Azure caching is now called Windows Azure Shared Caching. In October 2012, Windows Azure Caching was released (as per the article you found) and is role (instance-based as opposed to shared) caching. Use the 'Caching' and not 'Shared Caching' as shared caching does not perform that well, is expensive, and generally replaced by (non-shared) caching. If you need it, shared caching is still available in the old Silverlight portal, which you get to by selecting 'Previous portal' on the drop-down menu on your name. Other features, such as reporting services, are currently only available in the 'previous portal'.
We are using the October 2012, Windows Azure Caching. We started using the co-located caching (cache cluster shared across each instance, but an azure data loss that brought down the storage container that our cache config was stored in caused an all day outage.
We just moved to using a dedicated cache role for our instances. In this configuration, the cache config is only used on startup. So far, the dedicated cache role has been working well.
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