0

I'm writing a basic RESTful service, and decided I'd use ASP.NET MVC 3 for the task. My application is going to be responsible for maintaining a persistent connection to a server per user (for now). I had assumed that Application_Start is the place to register static/shared state (like persistent connections), but after reading the documentation for Unity.MVC3, it appears that each request/response cycle will trigger the creation of services (by calling Application_Start).

The documentation I refer to says:

On every request, one UpperCaseService, one LowerCaseService and one ExampleContext are instantiated by DependencyResolver via Unity. At the end of the request, the ExampleContext is automatically disposed

After reading other documentation, and from what I already assumed, Application_Start would be called per AppDomain spawned (again assumed that this would be in the vicinity of how many cores there are on the server).

So, what would be an effective way of maintaining a set of persistent connections to a server, that survive the request/response phase, and if possible, are shared between all AppDomains that the IIS server has created?

It might help to mention that this web service is only going to be consumed by another web site. It is essentially an Authentication Proxy server, however, in the future, it is going to do a lot more. Therefore, I can't just cache the response, as future requests will be required, and reauthenticating is not an option.

Josh Smeaton
  • 47,939
  • 24
  • 129
  • 164
  • In IIS, an directory is defined as an application. That "application" is mapped to an appPool (which is a process). Many apps can be mapped to an appPool process. In a process, the CLR will create a default appDomain (think of as a managed boundary in a process). Your ASP.Net application runs in that process and in that appDomain - not multiple appDomains per core. Each request will be served out of a thread pool. If you store state in-proc, it will be accessible to your app within that appDomain ... BUT. – bryanmac Jan 05 '12 at 01:02
  • BUT ... the issue you have to be concerned about is appPools can recycle (by default). So, your state is fragile - which is not very RESTful either ... – bryanmac Jan 05 '12 at 01:03
  • ... even though many apps can be mapped to that appPool process (hosting, shared management), your app will be mapped to 1. Putting apps in different processes provides isolation and ability to run as different identities etc... – bryanmac Jan 05 '12 at 01:05
  • It sounds like you're defining some sort of persistent socket application and not a restful http server. WCF is another option to look at it since it's flexible and can be a configured for TCP/persistent. – bryanmac Jan 05 '12 at 01:07
  • @bryanmac 4 comments would have been great as an answer :P The end game is to deploy to mono, so WCF isn't a great option unfortunately. I guess my question comes down to a lack of understanding on how IIS manages applications. I can work around the recycling issue at a later date, and already have ideas on how to achieve this. For now, it's enough to instantiate a TCP connection, and store it for a short amount of time. – Josh Smeaton Jan 05 '12 at 01:44

1 Answers1

1

If you want to survive AppDomain restarts and share state between multiple ASP.NET applications you will have to go out of the IIS process and store this in a central location that is accessible from all applications. A database is a good candidate.

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
  • 1
    What needs to be shared are TCP connections. Not between different applications, but within what I assume to be multiple threads or app domains. I'm not really sure how many app domains are used for an ASP.NET application, and if Application_Start is called for each request or not. This is the first ASP.NET app I've written. – Josh Smeaton Jan 04 '12 at 12:33