c# .net in-memory persistence

Question

I would like to have a "user message" available for every request sent back by the server. If there is not a user message, the message goes back blank. If there is one, an icon is activated on each user screen after their request is completed.

[edit] The "user message" is something that is being set by an administrator for the application I'm deploying. The administrator can enter text into a field and click a button to send this message to every other user of the system. Any time another user performs any kind of action, the current user message is attached to the JSON response and handled by the front end.

In order to optimize this, I want the message to be stored in memory (not in the database).

I have tried to use static. I have tried to use HttpApplicationState. In both cases, the value of the user message is "blanked out" after some period of time. After some research, it appears that both statics and HttpApplicationState are subject to IIS and when it decides to recycle the application pool. (or some such)

This volatility of a static is mysterious: it should be static - so long as IIS itself lives, this variable should live. It should not be dependent on some kind of "reset" or whatever. The HttpApplicationState is some other situation that I don't fully understand.

I would like a way to store a value in a non-volatile variable that I can rely on. If I set this value today, it should be there tomorrow, or next week, so long as IIS is not stopped and restarted.

Any help?

---

here is what i have done to solve the problem as per the accepted answer below:

1. the user message is a sometime thing. so when the message gets set by some administrator, store the response in the database at that point in time and store it in the Application["UserMessage"] object.
2. when round-trips from users come in, the in-memory text for the user message gets added to the json return value.
3. the message can be cleared by the administrator at any time, which clears both the in-memory message and the database field.
4. when IIS decides enough is enough and recycles the application, the Application_Start() method (among other tasks) will also re-seed the user message from the database value that was stored when the user message was set (as per step 1).

now the application works as expected. no extra price is paid going to the database for every user request into the system - the user message always comes from memory. in addition to this, the database is updated or loaded for the user message very few times.

Answer 1

Application cache is a good place for it. The problem for you is, you think you cannot rely on it. Please see the later part of my answer where you will find how to make sure that the value is always there even if after iis restarts or iis recycles your application.

You can store the value in application cache. It can be done as follows

Application.Add(name,object)

Later you can retrieve it in each request by using this code

Application[name]

It works like session but the only difference is it is application wide and all the request from all user will get it. When you first time assign set the value, store it in db as well as application cache so that you can later make a query from db and store it in application cache if value is not there and then retrieve it from application cache.

You should restore the application cache from the database on Application_Start() event which fires every time the application starts or restarts. This way you can ensure that it is always in the application cache.

Answer 2

I would like a way to store a value in a non-volatile variable that I can rely on. If I set this value today, it should be there tomorrow, or next week, so long as IIS is not stopped and restarted.

In this case you cannot store this value in memory. The memory is something that is allocated for you by IIS to host the AppDomain of your application. IIS could recycle your application at any time and wipe out the memory. While IIS continues to live your application doesn't. So you cannot rely on it. The only reliable solution in this case is to persist this information in some non-volatile storage such as a file, database, ... the choice is really up to you but it should be out of the process of your AppDomain.