@PersistenceContext EntityManager thread-safety en Spring y Java EE

Question

EntityManager es no thread-safe por definición. Las especificaciones de servlets indican que en entornos no distribuidos y sin implementar SingleThreadModel, existe solo una instancia de servlet por definición.

Por lo tanto, en Java EE cuando se inyecta un EntityManager a través de la @PersistenceContext en el campo de servlet - no es hilo de seguridad:

public class MyServlet extends HttpServlet { 

    // Not thread-safe, should be using EMF instead. 
    @PersistenceContext 
    private EntityManager em; 
} 

1. ¿Es esto correcto decir que a pesar de que el ámbito predeterminado de los granos de la primavera es singleton, el EntityManager es seguro para subprocesos ya que Spring utiliza ThreadLocal para enlazar su transacción y EntityManager a ella?

2. ¿El ejemplo de Servlets anterior sigue siendo válido en Spring? ¿Todavía no es seguro para subprocesos?

3. ¿El enfoque ThreadLocal funciona solo para los beans gestionados por Spring y el servlet plano no es uno de esos?

4. Por lo que recuerdo, es responsabilidad del contenedor inyectar el EntityManager. En la implementación Glassfish Java EE, fue el servidor de aplicaciones quien descubrió el @PersistenceContext como punto de inyección.
   ¿Cómo se ve en primavera? ¿El Spring Framework es responsable de descubrir esas anotaciones o es responsabilidad del implementador de JPA?

Answer 1

Pregunta 2, 3 y 4 - Spring no presta atención a ninguna clase que no sea Spring Bean. Por lo tanto, Spring no le presta atención MyServlet clase. Por lo tanto la respuesta para

• 2) no es
• 3) solamente gestionados Spring Beans
• 4) es resortes responsabilidad, porque la primavera es el contenedor

para la pregunta 1). Funciona de esta manera, por lo que el uso de un administrador de entidad inyectado por resorte es efectivo para guardar los hilos.