With 2 web servers, will a singleton class have 2 instances?

With 2 web servers, will a singleton class hav开发者_如何学JAVAe 2 instances?

---

Both the web-servers will have separate instances of their application processes be it .net or java. So Yes, both the servers will have their individual instances of your singleton class.

Regardless of the fact that these two web servers are two different physical machines, even if they are on the same server, they will definitely run entirely on different processes. Each process will load its objects in memory separately from any other process.

specifically in case of asp.net - Even in the single web server, each site will cause separate instance of the Singleton class. Because each site in asp.net worker process is loaded in separate application domain, no two domains can interfere between each others' objects. So in case of asp.net even the single web server having single asp.net worker process can/will have multiple instances of the singleton class each separate from another.

---

Yes, you have a Singleton per each JVM and even class loaders.

See this When is a Singleton not a Singleton? article (for Java).

---

What do you mean by "2 web servers"? Static field (in singleton) is scoped to Application Domain (in .net).

So if your two web servers run in two separate application domains, then yes, otherwise no.

---

In fact you may well have 2 instances of a singleton calls in ONE web server, if its part of a webapp that is deployed twice.

In Java, the classloader is part of a class's identity. You can load the same class twice with different classloaders, and all static fields will exist twice. C# has a similar mechanism.

---

It is possible to create a web server that will multiplex over everything - connections, listening sockets, even interfaces. It will be still one instance of the class, only one thread, and on top of that a pretty small memory footprint. The caveat is, that while from most practical standpoints it will look like two servers, it will still be only one server (and if it crashes, it crashes whole...)

This approach is not nearly as popular as multi-threaded webservers though, because while lighter on hardware, it is harder for developer to handle - you have to explicitly multiplex between everything, and juggle all connections in non-blocking calls. If you spawn some extra threads, the OS takes away a lot of work from you, allowing you to write a more feature-rich server easier.

Of course even in a single-threaded server spawning of a second server in a separate task is still possible, just by the user/admin/whoever executing the binary again, with different config. It takes some pretty fancy programming to prevent that from happening.

---

This is why JSP/Servlets provide the idea of "session" and "application" data. These should be shared across servers in a multi-server environment.

---

As an extension of this question, specifically for .NET web apps, you also need to pay attention to SessionState handling. Assuming that sessions aren't "sticky" (user stays on one web server once session is established), you'll need to change SessionState to out-of-process. This can either be the ASP.NET session state server, or SQL Server, but the key point to remember is that SessionState isn't automatically shared across servers, unless you make it shared by going out-of-process. Also, anything you put in SessionState needs to be serializable; add the [Serializable] attribute to any classes you use in SessionState.