¿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 solo exista una única instancia de un Servlet dado que atienda múltiples solicitudes. Esto puede llevar a problemas de subprocesos en variables de instancia.

Mi pregunta es, ¿es seguro inyectar un EJB utilizando 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. Parece que este también sería el instinto de otros programadores: No inyectar en servlets

Sin embargo, he saltado a la conclusión incorrecta. Claramente, lo que se inyecta en el servlet es un proxy. Bajo el capó, ¿el contenedor realmente atiende cada solicitud con una instancia diferente y mantiene la seguridad de los hilos? Como sugiere este foro: Inyecte en los servlets

Parece que hay muchas opiniones conflictivas. ¿QUÉ ES CORRECTO?

Answer 1

Su referencia " No inyectar en servlets " No menciona nada sobre ejbs o @ejb anotación. Habla de no subprocesar objetos seguros como PersistenceContext.

Según la especificación EJB, puede acceder a ejbs desde diversos clientes remotos, incluidos los servlets (Especificación EJB 3.0 (JSR-220) - Sección 3.1). Inyectar 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. Así que no hay nada especial en la anotación de @EJB con respecto a los EJB obtenidos.

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

Answer 2

Es seguro inyectar un EJB en un Servlet como una variable de instancia de Servlet, siempre que el EJB esté sin estado. NUNCA DEBE inyectar un Bean de Stateful en un Servlet.

Debe implementar su EJB sin estado, ya que no contiene ninguna variable de instancia que a su vez tenga un valor con 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 un PersistenceContextFactory como una Variable de instancia de EJB y luego obtendrá una instancia del administrador de entidades de la Fábrica en el método del EJB.

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

Mientras cumpla con las reglas mencionadas anteriormente, debería ser seguro para subprocesos inyectar un Bean sin estado en un Servlet

Answer 3

Es una bolsa mixta.

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 código auxiliar, el contenedor serializará el acceso a los métodos.

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

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

Answer 4

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

El motivo de esto es que no hay nada explícito en la especificación EJB que diga que las interfaces domésticas EJB tienen que ser seguras para subprocesos. 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á que ver cómo están implementados por la biblioteca que está utilizando. La parte de anotación se expandirá en un localizador de servicios para que no le compre nada.