Con 2 servidores web, ¿una clase singleton tendrá 2 instancias?

Question

Con 2 servidores web, ¿una clase singleton tendrá 2 instancias?

Answer 1

Ambos servidores web tendrán instancias separadas de sus procesos de aplicación ya sea .net o java. Así que Sí, ambos servidores tendrán sus instancias individuales de su clase singleton.

Independientemente de que estos dos servidores web sean dos máquinas físicas diferentes, incluso si están en el mismo servidor, definitivamente se ejecutarán completamente en procesos diferentes. Cada proceso cargará sus objetos en la memoria por separado de cualquier otro proceso.

specifically in case of asp.net - Incluso en el único servidor web, cada sitio causará una instancia separada de la clase Singleton. Debido a que cada sitio en el proceso de trabajo de asp.net se carga en un dominio de aplicación separado, no hay dos dominios que puedan interferir entre los objetos de los demás. Por lo tanto, en el caso de asp.net, incluso el único servidor web que tiene un único proceso de trabajo asp.net puede/tendrá múltiples instancias de la clase singleton, cada una separada de otra.

Answer 2

Sí, tiene un Singleton por cada JVM e incluso cargadores de clase.

Consulte este artículo When is a Singleton not a Singleton? (para Java).

Answer 3

¿Qué quiere decir con "2 servidores web"? El campo estático (en singleton) tiene el ámbito Application Domain (en .net).

Así que si sus dos servidores web se ejecutan en dos dominios de aplicación separados, entonces sí, de lo contrario no.

Answer 4

De hecho, es posible que tenga 2 instancias de llamadas únicas en UN servidor web, si es parte de una aplicación web que se implementa dos veces.

En Java, el cargador de clases es parte de la identidad de una clase. Puede cargar la misma clase dos veces con diferentes cargadores de clases, y todos los campos estáticos existirán dos veces. C# tiene un mecanismo similar.

Answer 5

Como una extensión de esta pregunta, específicamente para aplicaciones web .NET, también debe prestar atención al manejo de SessionState. Suponiendo que las sesiones no son "adhesivas" (el usuario permanece en un servidor web una vez que se establece la sesión), tendrá que cambiar SessionState a fuera de proceso. Este puede ser el servidor de estado de sesión ASP.NET o SQL Server, pero el punto clave que hay que recordar es que SessionState no se comparte automáticamente entre los servidores, a menos que lo haga compartido al salir fuera de proceso. Además, todo lo que pongas en SessionState necesita ser serializable; agregue el atributo [Serializable] a cualquier clase que use en SessionState.

Answer 6

Es posible crear un servidor web que multiplexará todo: conexiones, conectores de audio, incluso interfaces. Seguirá siendo una instancia de la clase, solo un hilo, y además una pequeña huella de memoria. La advertencia es que, aunque desde el punto de vista más práctico, se verá como dos servidores, seguirá siendo solo un servidor (y si se bloquea, se bloquea por completo ...)

Este enfoque no es tan popular como el multi sin embargo, los servidores web con hebras, porque aunque son más ligeros con el hardware, es más difícil de manejar para el desarrollador: tienes que multiplexar explícitamente todo y hacer malabares con todas las conexiones en llamadas que no bloquean. Si genera algunos hilos adicionales, el sistema operativo le quita mucho trabajo, lo que le permite escribir un servidor más rico en funciones más fácilmente.

Por supuesto, incluso en un servidor de subproceso único, el desove de un segundo servidor en una tarea separada sigue siendo posible, solo por el usuario/administrador/quien ejecute el binario nuevamente, con configuraciones diferentes. Se necesita una programación bastante sofisticada para evitar que eso suceda.

Answer 7

Es por eso que los JSP/Servlets brindan la idea de datos de "sesión" y "aplicación". Estos deben ser compartidos entre servidores en un entorno de servidores múltiples.