sessionscoped managed bean vs stateful ejb

Question

Si tengo un @ManagedBean que es @SessionScoped, ¿por qué debería usar un EJB @Stateful? Lo usé antes para los carritos de la compra y para mantener un estado conversacional, pero como un frijol administrado se mantendrá durante la sesión del usuario, puedo almacenar el estado allí, luego llamar a SLSB para la lógica de negocios. ¿Es eso correcto? Si es así, los ejbs con estado se dejarán para aplicaciones más específicas, como cuando necesita transacciones, etc.

Answer 1

Muy a menudo, los beans de sesión sin estado se pueden utilizar para una gran cantidad de problemas comerciales.

Stateful no significa necesariamente que solo un servidor remoto mantiene el estado, aunque esta es ciertamente una de las opciones. Un cliente de Swing remoto podría enviar primero un montón de datos a un bean de sesión con estado, aferrarse al stub y luego enviar algunos comandos que operan con estos datos. Esto evita que el cliente tenga que enviar la misma (gran cantidad de) datos todas y cada una de las veces.

En el caso de uso remoto, de hecho refleja el uso de la sesión HTTP cuando se utilizan clientes web (navegadores). La principal diferencia es que la sesión es por bean aquí, mientras que con la sesión HTTP, la sesión es un ámbito compartido por muchos beans. Dado que la sesión HTTP se basa en cookies, y las cookies son globales para un dominio para todo el navegador, la sesión HTTP no admite directamente varias sesiones del mismo cliente (por ejemplo, por pestaña o por ventana). Esto es trivial con beans de sesión con estado.

Sin embargo ...

clientes remotos oscilación hablando con EJB remotos no son tan comunes.

En el contexto que describió en su pregunta, normalmente utilizará EJB locales y almacenará la mayoría del estado en la sesión HTTP (tenga cuidado al compartir!) Y estos días en el alcance de vista o conversación.

Por último, ¿cuándo usar los beans de sesión con estado en este escenario?

Un caso de uso importante es el extended persistence context en JPA. Normalmente, con un administrador de entidades de ámbito transaccional, cuando una entidad cruza el límite transaccional de una llamada a un método EJB, se desconectará. Si desea (con optimismo) bloquear una entidad entre las interacciones del usuario, esto no es deseable. Perderás el bloqueo.

Con un contexto de persistencia extendida, la entidad permanece adjunta y los bloqueos son válidos cuando regresa de una llamada al bean de sesión con estado. Esto es muy útil para la funcionalidad de vista previa para asegurar que nadie más ha realizado ningún cambio en la entidad cuando está bien después de la vista previa. O, de hecho, para un carrito de compras en el que desea asegurarse de que durante algún tiempo el artículo no pueda venderse a otra persona mientras esté en el carrito.