java - ¿Los interceptores en Struts2 roscan inseguro?

thread-safety

Question

Entiendo que las clases de acción de Struts2 son seguras para subprocesos, porque las acciones se colocan en la pila de valores. La Value Stack a su vez es una parte del Contexto de Acción. Como el contexto de acción es local de subprocesos, los valores almacenados en el contexto de acción (incluida la pila de valores) son únicos por subproceso. Entonces, las acciones son seguras para hilos.

Pero considere los interceptores: son realmente útiles, hacen todos esos pequeños trabajos tediosos para el programador ... como validaciones, obteniendo los valores de param, etc. Pero lo que hay que considerar es que: los interceptores se pueden compartir entre múltiples solicitudes. Entonces, ¿eso hace que los interceptores se vuelvan inseguros?

Con esta pregunta en mente, intenté navegar por la red para encontrar algunos buenos artículos relacionados con este problema. Y encontré un artículo muy bueno, donde han mencionado claramente con un ejemplo cómo los interceptores NO son seguros para hilos.

La página web es: http://www.bullraider.com/java/struts2/tutorials/interceptors-and-thread-safety

Lo que llegué a saber de este artículo es que la razón principal detrás de que Interceptors sea inseguro es que los interceptores se crean solo una vez. es decir, cada interceptor tiene solo un objeto. Por lo tanto, los campos de instancia no son seguros cuando la misma instancia de un Interceptor se comparte entre subprocesos.

Al final del artículo, se menciona que hay casos en los que incluso los interceptores son seguros para subprocesos. Pero ellos no mencionaron ninguno de esos casos. Navegué por la red para encontrar la respuesta ... pero fue en vano :(

¿Alguien puede decirme o proporcionarme un enlace, donde puedo averiguar cómo hacer que los interceptores sean seguros para subprocesos (o cuáles son los escenarios cuando un interceptor es seguro para subprocesos)?

Answer 1

Cualquier interceptor que no use campos de instancia u otro estado compartido es seguro para subprocesos:

Por ejemplo, observe todos los interceptores incorporados que analizan los parámetros y cookies de solicitud HTTP, registro, verificación de acceso, manejo de excepciones: no usan campos de instancia para estado mutable (*) sino que simplemente operan en la instancia de ActionInvocation que obtienen como parámetros.

(*) algunos tienen campos de instancia para los parámetros de configuración que se establecen cuando Struts se inicia (en un único hilo), como ExceptionMappingInterceptor , o campos de instancias seguras para hilos como Logger in LoggingInterceptor .

Si planea escribir su propio Interceptor , trabaje solo con el parámetro ActionInvocation que se transfiere y con las variables locales en su método de intercept() . Evite la tentación de synchronized su método de interceptación o poner cosas en un bloque synchronized{} ; esto creará un cuello de botella con el enfoque de Struts en una sola instancia para los Interceptores.

Para responder las preguntas de los comentarios:

(1) ¿Cómo es que crear una instancia de acción para cada tema no afecta el rendimiento? ¿O sí?

Con las JVM modernas, el costo de crear un objeto es insignificante. No debe haber un efecto apreciable en el rendimiento si mantiene sus acciones livianas evitando costosas inicializaciones, por ejemplo, al no crear conexiones de bases de datos dentro de una acción pero utilizando un grupo de conexiones.

(2) ¿NUNCA recomienda NUNCA utilizar la pila de interceptor predeterminada, y siempre usa la pila de interceptor personalizada (donde se eliminan todos los interceptores no utilizados que usan variables de instancia) para que sea segura para subprocesos?

No creo que ninguno de los interceptores predeterminados que se envían y configuran con Struts 2 no sean seguros para subprocesos; incluso si usan campos de instancia (porque se usan solo para la configuración o en sí mismo, como el Logger ).

Desde mi experiencia personal, solo deberías tocar / cambiar la pila del interceptor si tienes una buena razón (la seguridad de los hilos de los interceptores incorporados no es una). Muchas cosas se comportan / rompen de forma inesperada si cambia las pilas: ejecutar una de las pilas integradas como "predeterminado" o "paramPrepareParam" ahorra mucha frustración en el largo plazo. Agregar sus propios interceptores personalizados suele ser menos perjudicial que eliminar / reorganizar los interceptores de una pila existente.

Answer 2

Posiblemente relacionado, la clase ScopeInterceptor.java podría tener un problema de seguridad de subprocesos: Problema de seguridad de subprocesos Java en la clase ScopeInterceptor de Struts.