Options for storing Session state with SharePoint

Question

I have written a user control for our SharePoint site that builds an HTML menu - this has been injected into the master page and as such ends up rendering on all pages that use it. There are some pretty computationally expensive calls made while generating this HTML and caching is the logical choice for keeping the page loads snappy. The HttpRuntime Cache has worked perfectly for this so far.

Now we are embarking down version 1.1 of this user control and a new requirement has crept in to allow per-user customization of the menu. Not a problem, except that I can no longer blindly use the HttpRuntime Cache object - or at least, not use it without prefacing the user id and making it user specific someway.

Ideally I would like to be able to use the ASP.NET Session collection to store the user specific code. I certainly don't need it hanging around in the cache if the user isn't active and further, this really is kind of session specific data. I have looked at several options including it in the ViewState or enabling Session management (by default it is disabled for a good reason). But I am really not all that happy with either of them.

So my question is: How should I go about caching output like this on a per user basis? Right now, my best bet seems to be include their user id in the Cache key, and give it a sliding expiration.

Answer 1

I use ViewState on a fairly large MOSS 2007 deployment (1000+ users) for custom webparts and pages, and I haven't noticed a detrimental effect on the deployment performance at all.

Just use it, is my advice.

Answer 2

I don't understand why you wouldn't use SharePoints built in web part caching mechanism for this on a per user basis (Personal) - its exactly what its designed for.

http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.webpartpages.webpart.partcacheread.aspx

Answer 3

It's worth pointing out that I believe the 'end of days' link providing is relevant for SPS2003 not MOSS2007 - afaik MOSS integration into Asp.Net means that the mentioned issue is not a problem in MOSS.