¿Es seguro inyectar un EJB en un servlet como una variable de instancia?

Question

Todos sabemos que en el nivel web existe la posibilidad de que exista una sola instancia de un Servlet dado que atienda múltiples solicitudes. Esto puede llevar a problemas de enhebrado en variables de instancia.

Mi pregunta es, ¿es seguro inyectar un EJB usando la anotación @EJB en un servlet como una variable de instancia?

Mi instinto inicial sería no, bajo el supuesto de que la misma instancia del EJB atendería múltiples solicitudes al mismo tiempo. Parecería que esto también sería el instinto de una serie de otros programadores: Don't inject to servlets

Sin embargo, he saltado a la conclusión equivocada. Claramente, lo que se inyecta en el servlet es un proxy, bajo el capó ¿realmente el contenedor sirve cada solicitud con una instancia diferente y mantiene la seguridad del hilo? Como este foro sugeriría: Do inject to servlets

Parece que hay muchas opiniones contradictorias. ¿¿¿CUAL ES CORRECTA???

Answer 1

Su referencia "No inyectar a servlets" no menciona nada sobre ejbs o @ejb annotation. Habla de objetos que no son seguros para subprocesos como PersistenceContext.

Según la especificación EJB, puede acceder a ejbs desde la variedad de clientes remotos, incluidos los servlets (Especificación EJB 3.0 (JSR-220) - Sección 3.1). La inyección de ejb utilizando la anotación @EJB es un método para obtener la interfaz EJB a través de la inyección de dependencia (sección 3.4.1), que es una alternativa a la búsqueda de objetos ejb en el espacio de nombres JNDI. Por lo tanto, no hay nada especial acerca de la anotación @EJB con respecto a los EJB obtenidos.

Por lo tanto, según EJB 3.0 Spec, es una práctica estándar obtener ejbs de servlets utilizando la anotación @EJB.

Answer 2

Creo que la respuesta simple es que no se garantiza que sea seguro.

La razón de esto es que no hay nada explícito en la especificación EJB que dice que las interfaces de inicio EJB deben ser seguras para hilos. La especificación describe el comportamiento de la parte del lado del servidor solamente. Lo que probablemente encontrará es que los esqueletos del cliente son realmente seguros para subprocesos, pero tendría que ver cómo la biblioteca que está utilizando implementan. La parte de la anotación simplemente se expandirá a un localizador de servicios para que no compre nada.

Answer 3

Es seguro inyectar un EJB en un servlet como una variable de instancia Servlet, siempre que el EJB sea apátrida. NUNCA DEBE inyectar un Bean Stateful en un servlet.

Debe implementar su EJB stateless en que no contiene ninguna variable de instancia que tenga un valor de estado (como el Contexto de persistencia). Si necesita usar el contexto de persistencia, entonces debe obtener una instancia del mismo en los métodos del EJB. Puede hacerlo teniendo una PersistenceContextFactory como una variable de instancia EJB y luego obtendrá una instancia del administrador de entidades de Factory en el método de EJB.

PersistenceContextFactory es seguro para subprocesos, por lo que se puede inyectar en una variable de instancia.

Como siempre que cumpla con las normas antes mencionadas, debe ser seguro para subprocesos para inyectar un frijol sin estado en un servlet

Answer 4

Es una mezcla.

Los beans de sesión sin estado se pueden inyectar y son seguros.Esto se debe a que incluso si se utiliza una única instancia de un apéndice, el contenedor serializará el acceso a los métodos.

Creo que lo que dice inferreddesign es no es verdad. No importa si el bean de sesión sin estado usa un contexto de persistencia. Solo una persona que llama tendrá acceso a una única instancia de bean al mismo tiempo, por lo que, aunque el contexto de persistencia no es seguro para subprocesos, el EJB protege contra el acceso múltiple a la misma. Piense en ello como si cada método de bean de sesión tuviera aplicada la palabra clave sincronizada.

El problema principal con la inyección de un EJB en un Servlet, creo que es el rendimiento. La instancia de stub único se convertirá en un área importante de contención cuando varias solicitudes se ponen en cola mientras se espera que se ejecute un método de bean de sesión.