ASP.NET session state provider in Azure [closed]

Question

As far as I know, the current situation is this:

1. Use SQL session state provider is possible (as I've read somewhere) but it's not supported by Microsoft. So it could stop working in the future. Also it needs a WorkerRole to delete the outdated data.
2. Azure AppFabric Caching Service is still in CTP.
3. TableStorageSessionProvider is a piece of code in the Azure training kit that is not recommended for production code.

What would you choose?

Atonement

Answer 1

If you're going live this week, I'd recommend the SQL Azure session state provider. There's an excellent blog post here that provides everything you'll need.

You're correct in that this solution isn't officially supported by Azure. However, it should work fine for now, and you can very easily shift to Azure AppFabric Caching (as suggested by Igor) once that goes live.

**EDIT 6/16/2014 ** See Azure Redis Cache (Preview) ASP.NET Session State Provider section of MVC movie app with Azure Redis Cache in 15 minutes

EDIT 5/23/2012 Lots of changes since this answer. As of August 2011, cache in SQL Azure is officially supported, via Universal Providers. See more info on this blog post. Pricing starts at $4.99 for a 100MB database.

AppFabric Cache is live as of May, 2011. Cache starts at 128MB for $45. Details of the AppFabric Cache are here. Note that there are hourly quotas in place on number of transactions, number of connections, and bandwidth (as well as storage capacity).

EDIT 6/7/2012 Yet another update: With the Spring 2012 release, there's now the ability to create a cache using a percentage of RAM in your existing Web or Worker roles (costing nothing), as well as a new Cache Role to create dedicated high-speed cache within your deployment (for the cost of the instances). Scott Guthrie blogged about it here. These features are available in the new v1.7 SDK.

Induna

I agree. The switchover from SQL to AppFabric/Azure is simply a web.config change. Go for what works now and upgrade later. – Radley

humm... but it needs a WorkerRole just to clean the outdated data, that means pay for a extra small instance 24x7 :( It will be a problem since the solution contains just a WebRole. I didn't count with that, and I don't think the customer is gonna be happy with it haha – Atonement

You don't need a separate worker role. Just combine that into your existing web role. Add the Run() method and you're good to go. – Induna

good idea. but when the run method in a webrole is called? – Atonement

Run() is called right after the OnStart() completes, so the role instance is now in the load balancer mix. So you can run timed threads, queue-listeners, whatever. You can even listen in on a tcp port (this is new to Azure 1.3 for Web Roles). Just like a worker role. – Induna

For those following this thread: AppFabric Cache is live, in production. Info, pricing, and SLA at msdn.microsoft.com/en-us/library/gg602420.aspx#CACHING_FAQ – Induna

@David: You might want to make that it's own answer as it's easy to miss as a comment! – Rendarender

Great that you're keeping this answer up to date DMak – Tarango

Answer 2

IMHO: Azure AppFabric Caching Service. It's strategically where they're going and they'll likely be done with it before you finish development.

Loxodromic

I could finish development this week, that is the problem :P Probably it would be on production on Friday. – Atonement

Just a subjective note: We spent over two weeks setting up and testing failover in AppFabric Cache. The reason was a combination of faults from our side (attempting without AD, attempting with non-admins in AD, firewalls, etc) and AppFabric giving some weird errors/behaviour (needs to point to a network share (on one server?), if share is down AppFabric Cache wouldn't start, etc) and and lack of similar experience on the internet (fresh release). It felt more like a version 0.9. Once running it seems to work fine though. – Radley

It sounds like this was the on premise version of AppFabric cache you were testing? – Chao

Answer 3

As I mentioned in a comment above, the AppFabric Cache is now live, in production. Details, including pricing and SLA, are here. Highlights of the production release:

• Availability in all data centers
• Ability to consume cache from 128MB to 4GB
• Transactional SLA (# of cache transactions per second)

Through the portal, once you create your cache namespace, you simply click a button that generates web.config/app.config snippets that you copy 'n' paste. It's that simple.

Induna