java - funciona - struts 2 pdf

¿Por qué las clases de acción struts no son seguras?

Question

Puedo leer en muchos sitios web que las clases de Struts Action no son seguras para subprocesos. No puedo entender por qué esto es así.

También leo un libro que dice "Las clases de acción de Struts se almacenan en caché y se vuelven a usar para la optimización del rendimiento a costa de tener que implementar las clases de acción de manera segura para hilos"

¿Cómo se relacionan las clases de acción de almacenamiento en caché y la seguridad de subprocesos? .

Answer 1

¿Cómo se relacionan las clases de acción de almacenamiento en caché y la seguridad de subprocesos?

Si almacena en caché y reutiliza instancias de una clase, permitiendo que varios hilos accedan a la misma instancia simultáneamente, entonces la clase no es inherentemente segura para subprocesos *. Si tuviera que colocar una instancia mutable o campos estáticos en la clase, los resultados en concurrencia serían inesperados y problemáticos. Por otro lado, si cada hilo tiene su propia instancia de la clase, entonces la clase es intrínsecamente segura para subprocesos.

• Las clases de acción de Struts 1 no son seguras para subprocesos. No debe colocar ningún campo mutable en la clase, sino que debe usar una clase Form Bean para los campos de formulario pasados ​​a la acción.
• Las clases de acción de Struts 2 son seguras para subprocesos. Se crean instancias de copias nuevas para cada solicitud y colocar campos de instancia en la clase es un concepto central en el marco.

* Si la instancia o el campo estático es inmutable, entonces está bien para múltiples hilos acceder a él simultáneamente.

Answer 2

¿Por qué no crear un nuevo objeto de "acción" por solicitud? ¿Qué hay en el mundo?

Debido a que Struts es tan viejo, cree que crear un objeto más por ciclo de solicitud es tan costoso como pagar un dólar por un café. (es decir, muy caro, porque es realmente viejo).

Answer 3

si cualquier clase se almacena en caché y se reutiliza, existe el riesgo de corrupción en los accesos simultáneos por varios subprocesos. En una aplicación web, cada solicitud se maneja en un hilo. Supongamos que tiene 10 instancias de una acción, pero su contenedor maneja 20 solicitudes; en este caso, sus 10 acciones se reutilizan porque tiene más solicitudes en vuelo que las acciones disponibles para atenderlas.

El problema de la seguridad del hilo solo asoma la cabeza si hay algún estado que se reutilice en la acción. Si ese es el caso, una acción que está dando servicio a una solicitud puede establecer un valor en la variable compartida, pero luego otro hilo podría tomar el control, y la acción podría modificar nuevamente la variable compartida. En ese caso, cuando el hilo original toma el control, el estado compartido ha sido modificado.

La forma más fácil de lidiar con esto es configurar tu stack para que siempre use una nueva acción, o asegúrate de no tener un estado compartido en tus acciones.

Answer 4

Al observar la fuente real de los puntales, verá que devuelve las clases de acción instanciadas. y así sucesivamente, dos solicitudes pueden golpear la misma variable de instancia, creando muchos problemas si no está sincronizada correctamente.

protected Action processActionCreate(HttpServletRequest request,
    HttpServletResponse response, ActionMapping mapping)
    throws IOException {

    // Acquire the Action instance we will be using (if there is one)
    String className = mapping.getType();

    Action instance;

    synchronized (actions) {
        // Return any existing Action instance of this class
        instance = (Action) actions.get(className);

        if (instance != null) {
            return (instance);
        }
   .......
    }
.....
}