¿Por qué se combinan los EJB sin estado?

¿Cuál es la razón por la cual los servidores de aplicaciones agrupan los EJB sin estado?¿Por qué se combinan los EJB sin estado?

Entiendo que es útil controlar la carga de trabajo de la aplicación para invokations entrantes, pero esto solo justifica la agrupación de los EJB de ese servidor como FAÇADE con el cliente invocador.

¿Tiene algún beneficio agrupar los EJB internos (aquellos que no están expuestos y que solo se invocan internamente para realizar la lógica de negocios)? en lugar de usar una instancia única compartida (como Spring lo hace).

Puedo pensar al menos en una desventaja: un EJB interno muy utilizado podría actuar como un cuello de botella.

Fuente

2012-01-16 edutesoy

Beans de sesión sin estado Los EJB no son necesariamente seguros para subprocesos. Pueden contener recursos como sesiones JMS que no se pueden compartir con más de un hilo a la vez, por lo que el servidor los combinará para que puedan servir varias solicitudes para el mismo bean al mismo tiempo (los recursos JMS también se agrupan, pero estoy solo usando eso por el bien del ejemplo).

Fuente

2012-01-16 19:02:31 Dev

Si no tiene estado, entonces no hay ningún estado que pueda ser amenazado por concurrencia, entonces no pueden aparecer condiciones de carrera, por lo tanto, son seguros para subprocesos, ¿estoy equivocado? Sí, sé que tienen algún estado, como los recursos inyectados, pero ¡quizás no deberían llamarse apátridas! :) tomo la respuesta como correcta. – edutesoy

@edutesoy Estoy de acuerdo con su explicación. Pero por qué el estado se mantiene entonces. –

También me gustaría saber por qué se agrupan los EJB apátridas. Pero quiero saber por qué se agrupan en lugar de crearse y destruirse a pedido. El hecho de que las instancias se puedan reutilizar para solicitudes no relacionadas complica significativamente la implementación de beans sin estado (significa que debe ser increíblemente cuidadoso con el uso de campos de instancia), y no veo ningún beneficio significativo para él.

Específicamente, no veo ningún beneficio en el rendimiento. Busqué la implementación de frijoles sin estado en JBoss (6, IIRC), y es solo la instancia del frijol en sí la que se agrupa; la plomería para manejar la invocación del método se recrea desde cero cada vez que se usa. Eso significa que el único ahorro de rendimiento es la creación de un solo objeto, que debería ser una cantidad de tiempo trivial. La única situación en la que puedo ver que no es trivial es si el bean adquiere recursos pesados, y se aferra a ellos entre invocaciones. Sin embargo, en ese caso, el bean realmente se está usando como un conjunto glorificado y mal administrado; ¡la solución correcta sería agrupar el recurso directamente!

Ahora, EJB ha existido por mucho tiempo. Cuando salieron por primera vez, la creación de objetos era costosa, por lo que tenía sentido agruparlos. Pero esos días se han ido. ¿Por qué la agrupación no se eliminó en EJB3?

Fuente

2012-01-16 19:32:31

Bueno, supongo que si tiene miles de solicitudes concurrentes, tiene sentido agruparlas, o incluso más, para crearlas como @Singleton, siempre y cuando esté seguro de que son seguras para hilos, en lugar de tener miles de instancias en la memoria. –

Si el bean es seguro para el hilo, entonces sí, un singleton es ideal. Pero si no, la carga de memoria de las instancias combinadas y desechables será similar; Las instancias combinadas realmente le darían al recolector de basura * más * trabajo por hacer, porque viven lo suficiente como para escapar de la guardería. –

Esa es una gran afirmación. Supongo que depende del tiempo que lleva procesar cada solicitud y, por lo tanto, del tiempo que esos objetos gastan en el grupo. Si la mayoría de ellos se puede utilizar en cualquier momento, es posible que obtenga algún beneficio sobre la creación/destrucción. Esto también depende de las tendencias de tráfico, etc. Este es un análisis de grano muy fino IMO :) –

¿Por qué se combinan los EJB sin estado?

Respuesta

Cuestiones relacionadas