.NET Session Alternative in Global Scope

Quick question: Is there a "per-user" data storage object (similar to Session) that I can store data in the global scope (similar to HttpRuntime.Cache)? Almost as if Session and HttpRuntime.Cache had a baby.

Full Background: I have a ASP.NET website that was originally written for a single thread. Now I changed it so that certain actions will spawn a background thread and the browser polls a service to get status updates.

The problem I am having with this is that certain pieces of data are stored into the HttpContext.Session[] object (membership authentication token, for example). These pieces of data need to be unique to each user and accessible to the background thread. Session is not available to the background thread.

I am aware of HttpRuntime.Cache but tha开发者_JS百科t would require micromanagement to segment out the users and to expire it at the same time the session is expired. Session, on the other hand, automatically expires this things at the right times that I want it too and is already used by things like the SqlMembershipProvider.

My question is, is there something that behaves similar to the Session but exists in the global scope?

I don't think there is anything like you need out of the box. I would do the following though:

1. User the application cache
2. Make the key the user ID or unique identifier
3. Store a Dictionary or some object list in the value for the user. Use this to store all the data you require.
4. Consider all prepending something on the user ID if you think there could be a conflict with the user unique identifier (eg domain etc)
5. Make sure to set an expiry on the cached data similar to the session (eg sliding)

Try passing the HttpContext.Current object to the method on your background thread. You should be able to access the session from the background thread through currentContext.Session assuming currentContext is the HttpContext parameter that was passed in.

See this blog post on how to safely access the HttpContext object from multiple threads.

No.

Since when application pool restarts all backgound activity die I suggest to think about moving user's state to your own database or external storage. Unfortunately you'll lose automatic session management benifits (sliding expiration), but if you need backgound activity it will work better - i.e. you'll be able to move your activity out of IIS process to separate process/machine if needed later.