Alcance de un controlador de resorte y sus variables de instancia

Question

¿Están todos los controladores en singleton Spring-MVC y se comparten entre diferentes sesiones y solicitudes?

Si es así, supongo que una clase de variables como

public String name; 

sería el mismo para todas las solicitudes y las sesiones? De modo que si el usuario X realiza una solicitud y name se establece en Paul, ¿el usuario Z también tiene a Paul como atributo?

En mi caso yo no quiero que el comportamiento pero preguntado si hay una manera más fácil, o más limpia POO-manera de tener sesión/Solicitar variables continuación session.getAttribute()/request.getAttribute()

Answer 1

para responder a su primera pregunta: sí , Los controladores Spring MVC son singleton por defecto. Un campo de objeto será compartido y visible para todas las solicitudes y todas las sesiones para siempre.

Sin embargo, sin ninguna sincronización podría encontrarse con todo tipo de problemas de concurrencia (condiciones de carrera, visibilidad). Por lo tanto, su campo debe tener el modificador volatile (y private, por cierto) para evitar problemas de visibilidad.

Volver a la pregunta principal: en la primavera puede utilizar solicitud- (ver 4.5.4.2 Request scope) y (véase: 4.5.4.3 Session scope) de ámbito de sesión frijoles. Puede inyectarlos a los controladores y cualquier otro botón (¡incluso singletons!), Pero Spring se asegura de que cada solicitud/sesión tenga una instancia independiente.

único que hay que tener en cuenta cuando la inyección de petición-judías y de ámbito de sesión en embarazos únicos es envolverlos en representación de ámbito (ejemplo tomado de 4.5.4.5 Scoped beans as dependencies):

<!-- an HTTP Session-scoped bean exposed as a proxy --> 
<bean id="userPreferences" class="com.foo.UserPreferences" scope="session"> 

    <!-- instructs the container to proxy the surrounding bean --> 
    <aop:scoped-proxy/> 
</bean> 

Answer 2

Sí, los controladores en Spring MVC son únicos. Entre varias solicitudes, la variable de clase se comparte y puede generar ambigüedad. Puede usar la anotación @Scope ("solicitud") encima de su controlador para evitar dicha ambigüedad.