Question

I need to create a singleton that would hold lots of data for a specific user. However, I am not unclear as to what the behavior of that singleton is in regard to multi-user app requests.

Here is the scenario:

On AppStart event I want to load common data for all users (from SQL) and store it as a collection somewhere within the ASP.NET storage mechanisms. (Any pointers as to where it should go would be greatly appreciated! I am thinking the cache.)

If I store that data in the cache, I would also have to create a static property in the Global.asax that would provide access to that the data from the cache.

This is not ideal because whenever an instance of any particular page, or generic handler, or what have you tries to query this data using Linq the property has to load the data from the cache… introducing latency. I need this data to be immediately available. (think of it as about 5K rows of data stored in collection of objects…)

I was thinking to use a singleton to get that data, and store it but I don’t know how it would behave between requests (and postbacks), as well as application instances, in terms of its persistence.

On PostAuthenticate event I want to get user specific data from SQL in the form of a collection. If i store it as a singleton (in a similar manner as the common data) i am not clear as to:

1. How is the data persisted?
2. What is the scope of that singleton (it should be for the duration of the user session).
3. How can I ensure that the data is immediately available to whatever needs to consume it?
4. What happens between post-backs to that singleton?
5. If another user logs in would another instance of that singleton be created for that specific application instance?

Answer 1

The HttpRuntime cache is a valid place to store your globally shared information. You just have to be aware that it can get purged at any time depending on the cache item settings and available memory. The property you use to access it needs to be able to re-load the data if it’s not found in the cache.

The runtime cache is an in-process memory store so the overhead for accessing objects is low.

Alternatively, you can store the data in a shared static property (“singleton”) and it will be available to all users (within a worker-process.)

You don’t want to store your user/session specific data as a singleton since static instances are shared across all requests. One option is to use Session state to store your user specific data. By default, Session state is also in-process…

One issue with Session state however is that, unlike the runtime cache, objects aren’t purged in response to memory pressure and will remain in memory until the session expires. This could be a scalability issue if you have lots of concurrent sessions and you are storing large amounts of data in Session state.

Another option is to use the runtime cache again, but use a composite key such as “UserData|” + UserId to store and retrieve data for each user. This allows you to set time limits on the cached item and the cache will purge old/low priority items if memory gets too low.