¿Por qué agrupar beans de sesión sin estado?

Question

Los beans sin estado en Java no mantienen su estado entre dos llamadas del cliente. En pocas palabras, podríamos considerarlos como objetos con métodos comerciales. Cada método toma parámetros y arroja resultados. Cuando se invoca el método, algunas variables locales se crean en la pila de ejecución. Cuando el método retorna, los locales se eliminan de la pila y, si se asignaron algunos objetos temporales, se recolectan de todos modos.

Desde mi punto de vista que no difiere del método de llamada de la misma instancia única por hilos separados. Entonces, ¿por qué un contenedor no puede usar una instancia de un bean en lugar de agrupar varios de ellos?

Answer 1

La agrupación hace varias cosas.

Uno, al tener un bean por instancia, tiene la garantía de que los hilos son seguros (los servlets, por ejemplo, no son seguros para subprocesos).

Dos, reduce cualquier posible tiempo de inicio que pueda tener un bean. Mientras Session Beans son "apátridas", solo necesitan ser apátridas con respecto al cliente. Por ejemplo, en EJB, puede inyectar varios recursos de servidor en un Session Bean. Ese estado es privado para el bean, pero no hay ninguna razón por la que no pueda evitar invocación o invocación. Por lo tanto, al agrupar beans, estas búsquedas se reducen a solo cuando se crea el bean.

Tres, puede usar el grupo de frijoles como un medio para reducir el tráfico. Si solo tienes 10 Frijoles en un grupo, solo obtendrás al menos 10 solicitudes trabajando simultáneamente, el resto se pondrá en cola.

Answer 2

El ciclo de vida de los beans de sesión sin estado es Does not existe, pasivo y MethodReady (pasivo o inactivo) state.To optimize per permanmance, en lugar de atravesar el bean desde create hasta el estado ready del método, el contenedor administra el bean entre activos y estados pasivos a través de las devoluciones de llamada del contenedor - ejbActivate() y ejbPassivate() administrando el grupo de beans.

sreenut

Answer 3

La agrupación aumenta el rendimiento.

Una instancia única que maneja todas las solicitudes/hilos daría lugar a una gran cantidad de contención y bloqueo.

Dado que no sabe qué instancia se utilizará (y varios subprocesos podrían usar una única instancia al mismo tiempo), los beans deben ser seguros para la fabricación de hilos.

El contenedor puede administrar el tamaño de la agrupación en función de la actividad real.

Answer 4

La transaccionalidad del modelo Java EE utiliza el contexto del subproceso para administrar el ciclo de vida de la transacción.

Esta simplificación existe para que no sea necesario implementar ninguna interfaz específica para interactuar directamente con el objeto UserTransaction; cuando la transacción se recupera del InitialContext (o se inyecta en el bean de sesión) se vincula a una variable local del subproceso para su reutilización (por ejemplo, si un método en su bean de sesión sin estado llama a otro bean de sesión sin estado que también utiliza una transacción inyectada.)