If a static class is put in App_Code, does that imply only one instance will be created, shared by different http requests?
Or each request still brings one request?
Thanks.
The static instances will be shared between all requests. See this question:
Are static class instances unique to a request or a server in ASP.NET?
You will have one instance for each worker process. You can have several worker processes on one machine handling requests for the same website (a "web garden").
The instance will be shared for all requests in that worker process only.
In addition, there can be two worker processes running for a short time during AppPool recycling, since it's done using a roll-over process (the old worker continues to process old requests while the new worker handles new ones).
There will be no instance at all!
static classes are never instantiated.
Related
In PHP (Apache + mod_php) the interpreter is restarted on every request. This is the execution model even if using PHP-fpm which keeps a few interpreters ready for requests.
Does an ASP.NET web app persist in IIS application pool waiting for requests or is there a new thread/process per request?
For example, would a static class variable persist across requests when one of those requests initializes it?
Yes, the value is persisted across requests.
A static class variable's (a field's) value is persisted and shared across all usage of the class (whether via an instantiated object or through the class reference itself). See http://msdn.microsoft.com/en-us/library/aa691162(v=vs.71).aspx
I have a single ASP.NET MVC 4 web application (MvcApplication which extends System.Web.HttpApplication) hosted on IIS 8. My application is running on a separate application pool in integrated pipeline mode. Maximum worker process count for this application pool is set to 1.
I understand, that application instances might get pooled and there might be multiple parallel threads, which will call Begin_Request/End_Request for the same instance of my application (AppDomain). Also I understand that if I set "Maximum worker process count" to more than 1 then there will definitely more than one instance of the application (AppDomain).
What I don't understand is how many calls to Application_Start will be issued and how many instances of my static variables (stored in MvcApplication and also there are some singletons, like NHibernate session factory etc.) will exist at a given moment.
Currently I have some problems with cleaning up .NET MemoryCache. Some users of my website are receiving old values from the cache, thus leading me to think that there might exist more than one instance of my global MemoryCache, even when I set "Maximum worker process count" to 1.
What is the maximal number of instances of my application static variables and singletons which will be run in parallel in a single worker process?
Is there any utility or script which would help me to enumerate all AppDomains on IIS?
I'm not sure if this applies to you, but HttpModule Initialize methods are called more than once because even though there is only one Application instance. One HttpApplication can spawn multiple HttpModule instances, so make sure those initializations are thread safe.
Application_Start and _End will fire only once per site start and stop with your current settings, so that will not be the issue. If you are using the HttpContext.Cache object, you might have the issue mentioned in this answer:
HashTable in HttpContext.Current.Cache
If you want, you can try using WinDbg and get a dump of what is going on in your process but that is a really heavy-handed tactic that probably won't shed as much light as just looking through the code. Not until you look at it a little harder, and are still stumped IMO.
Normally Servlets are initiated just once and web container simple spawns a new thread for every user request. Let's say if I create my own web container from scratch and instead of Threads, I simply create Servlets as Singleton. Will I be missing anything here? I guess, in this case, the singleton can only service one user request at a time and not multiple.
Normally Servlets are initiated just once and web container simple spawns a new thread for every user request.
The first statement is true, but the second actually not. Normally, threads are been created once during applications startup and kept in a thread pool. When a thread has finished its request-response processing job, it will be returned to the pool. That's also why using ThreadLocal in a servletcontainer must be taken with high care.
Let's say if I create my own web container from scratch and instead of Threads, I simply create Servlets as Singleton. Will I be missing anything here?
They does not necessarily need to follow the singleton pattern. Just create only one instance of them during application's startup and keep them in memory throughout application's lifetime and just let all threads access the same instance.
I guess, in this case, the singleton can only service one user request at a time and not multiple.
This is not true. This will only happen when you synchronize the access to the singleton's methods on an application-wide lock. For example by adding the synchronized modifier to the method of your servlet or a synchronized(this) in the manager's method who is delegating the requests to the servlets.
JavaEE used to have a mechanism for this - a marker interface called SingleThreadModel that your servlet could implement:
Ensures that servlets handle only one request at a time. This interface has no methods.
If a servlet implements this interface, you are guaranteed that no two threads will execute concurrently in the servlet's service method. The servlet container can make this guarantee by synchronizing access to a single instance of the servlet, or by maintaining a pool of servlet instances and dispatching each new request to a free servlet.
Note that SingleThreadModel does not solve all thread safety issues. For example, session attributes and static variables can still be accessed by multiple requests on multiple threads at the same time, even when SingleThreadModel servlets are used. It is recommended that a developer take other means to resolve those issues instead of implementing this interface, such as avoiding the usage of an instance variable or synchronizing the block of the code accessing those resources. This interface is deprecated in Servlet API version 2.4.
Containers could use this to instantiate a new servlet for each request, or maintain a pool of them, if they chose to.
This was deprecated in Servlet 2.4, for the reasons documented above. Those same reasons still apply to your question.
That's basically it.
I would question the motivations for creating your own container, with so many available for a wide range of purposes.
Looking at a very simple web project, hosted in IIS, with one simple aspx page, executing some code (get some data from a db and populate some controls), which of the following is true:
each page request shares the same instance of the codebehind class.
or each page request runs in its own instance of the codebehind class.
Does one thread/instance run against each aspx page. Or does one thread/instance cover multiple pages?
Im trying to understand, in a simple web project, that receives 100 page requests, will they run consecutively one after the other, or multiple instances/threads for each request?
Each request gets a new instance of the code-behind class.
One instance of the code-behind class serves one request.
Two requests at different points in time may run on the same thread from the thread pool.
Two requests that runs in parallell gets one thread each (I think; not 100% sure on if there are some corner cases that I am not aware of regarding the threading).
So, a web server can handle several requests in parallell, but there is of course a limit on how many requests that can be served at the same time.
There is one instance of the code behind class for each request.
Well, actually it's an instance of the aspx page class, that inherits from the code behind class. (That's why you are using the protected keyword for event handlers in code behind, so that the inheriting class can access them.)
There is also the case where you do a Server.Transfer or Server.Execute, then the request is transfered to another page instance.
There are several threads running in the IIS handling requests, and usually one request is handled in one thread, but a request can be moved from one thread to another in some situations.
If 100 requests arrive at the server, it will start processing a few of them in separate threads, and put the rest of them in a queue. Noteworthy is that the server will only process one page at a time from each user, so unless you use sessionless pages (to make them anonymous) it will not process two pages for the same user in parallel threads, which makes the whole threading part a lot easier.
Maybe take a look at asynchronous ASP.NET?
http://msdn.microsoft.com/en-us/magazine/cc163725.aspx
Normally a new thread is assigned to a new request.
"A normal, or synchronous, page holds onto the thread for the duration of the request, preventing the thread from being used to process other requests."
Is a static variable in a webservice shared between all running invocations of the webservice on a server?
In my case I want a server-wide sync-lock, and I beleive I can accomplish that with a single
private static Object syncHandle = new Object();
Is that correct?
Yes, they are all shared per AppDomain which is why, in general, they should not be used!
They should not be used, in general, because they are so unlikely to be used properly. Also because there are safer alternatives, like HttpContext.Cache, or even Session state.
Still, if you encapsulate all access to these static members, and if you handle locking correctly, then you'll have a safe implementation that may then turn out to be a bottleneck, with all threads contending for the shared resource. It's really better to do without.
Also, you seem to mean ASMX web services, but you should specify ASMX or WCF.
I believe they are shared as long as they are running in the same process. So two people requesting from the same server would have the same instance of the object. However, you can run different applications in a computer different process on IIS, in which case I'm pretty sure that instances to objects wouldn't be shared.
They are all shared unless you have a Web Garden. A web garden is multiple host process handling a single application. In this case each host will have its own static data.