How can multiple ASP.NET requests from multiple clients share information?

Imagine a website where individual clients can see each-other's presence - like a social network or a chatroom.

For example:

Client1 connects to my website.

The back-end C# code updates a static field to indicate Client1's presence.

Client2 connects to my website.

Will the back-end C# code for the second request see the information stored in the static field from the first request? Is there anything I need t开发者_JAVA百科o do to guarantee that these seperate instances of my ASP application are sharing static data?

It totally depends on what information are you trying to share. Various options can be :

• DataBase
• Cache
• Application Variables

Each of these options is suitable for specific needs. You need to identify your needs carefully and then analyze each of the options or their combination to find a perfect solution.

If you are looking to just share the presence information, you can look at this post here How to tackle this session problem in ASP.NET,VB.NET?

You can also use the Application state or Cache to share information across all your clients.

In an ASP.net application, application / cache would be one of the common ways to share information across the application.

However, you need to consider the following first to make sure it fits your specific needs.

When using application state, you must be aware of the various considerations:

1. Resources
2. Volatility
3. Scalability
4. Concurrency

Refer section "Application State Considerations" in the link above to know more about things that you need to consider before deciding on your choice.

If it is static fields that they are editing then it will be shared between the different users. The only time you should be concerned that a static object isn't being shared between the different threads is if you have different web servers hosting your app (such as a load balancing architecture) since it would be different application domain.

I would consider using a Windows service that the web application(s) can communicate through via WCF.

This will allow you a great degree of flexibility; it allows you to perform additional processing of data out of process (for example, aggregating presence statistics like "50 people in your extended network are online"). A Windows service also completely frees you from any limitations that in process state mechanisms have. It will allow you to load balance freely and let multiple applications consume its data.

If the data is expendable, make the service stateless. Otherwise, persist some/all/periodic data to a database, which will allow you to recover even if the service and/or websites go down.

Lastly, if you build an application that depends on a service, it is a potential single point of failure. The best installations use either a database or a synchronization mechanism to ensure redundancy on out of process services.

Edit: to give more detail on your original question, static members are available to all HTTP requests to the app domain that your ASP.Net site is running in. For what it's worth, static variables can also be designated (through attributes) with different levels of access, for example ThreadStaticAttribute.

In practice, static variables are a cheap/weak solution. You have to manually synchronize access and you have little control over expiration. You can implement a Cache-based solution with zero additional effort, or move to the aforementioned out of process methodology to support enterprise requirements.