EJB 3.1 Se necesita asesoramiento de diseño Singleton + JPA + JSF

Question

Dado: aplicación web JSF simple (sin costura), que tiene beans JSF llamando a algunos EJB que a su vez cargan y persisten las entidades JPA. Lo que quiero es utilizar @Singleton anotación para EJB e inyectar EntityManageren lugar deEntityManagerFactory:

@Singleton 
public class MyEJB { 
    @PersistenceContext(unitName = PERSISTENCE_UNIT_NAME) 
    protected EntityManager em; // not EntityManagerFactory 
} 

Spec dice que @Singleton es seguro para subprocesos, apoya la concurrencia y los atributos de transacción de la que (desde mi pov) hace que sea seguro para llamar desde beans JSF. También espero beneficios de rendimiento porque EntityManager no se recrean para cada llamada y son capacidades internas de almacenamiento en caché.

Mi principal preocupación aquí es crear operaciones/actualización de entidades JPA en la situación cuando tengo varios hijos únicos y, como resultado, el mismo número de EntityManagers de larga vida.

• ¿Qué pasa si uno Singleton actualiza una instancia de la APP y cómo estos cambios están pobladas a otros conjuntos unitarios?
• Como no puedo cerrar el administrador de entidades, ¿tengo que vaciarlo al cada actualización de entidad?
• ¿Sería mejor si estos pocos singleton compartirían el mismo administrador de entidad ?
• Vi solo algunos ejemplos de dicho diseño. ¿Por qué? ¿Hay algún problema grave con ?

¡Muchas gracias de antemano!

Answer 1

Espero también beneficios de rendimiento debido a que EntityManager no se recrea para cada llamada y sus capacidades internas de almacenamiento en caché.

Usted puede ahorrar algo de memoria utilizando únicos, pero usarlo en todas partes en su aplicación podría hacer realidad más lento, debido a que sólo hay un EJB para servir a todas las peticiones simultáneas de varios usuarios de su aplicación, los bloqueos de contenedores de acceso al EJB y cuando está ocupado atendiendo una solicitud, no puede atender otra solicitud. Sin embargo, esto se puede aliviar en cierto grado utilizando tipos de bloqueo (es decir, @Lock(WRITE) y @Lock(READ)).

Singleton son útiles para cuando se desea ejecutar una pieza de código periódicamente utilizando temporizadores EJB, o para actualizar una memoria caché periódicamente, etc.

¿Qué pasa si uno Singleton actualiza una instancia de la APP y cómo estos los cambios se completan con otros singletons?

No debería ser diferente a la forma en que se comportan los EJB no únicos.

Como no puedo cerrar el administrador de entidades, ¿debo limpiarlo con cada actualización de entidad?

Si usa CMT, no. Al final de cada transacción, todo se vaciará automáticamente.

¿Sería mejor si estos pocos singleton compartirían el mismo administrador de entidad?

Parece que la optimización prematura a mí. Simplemente deje que el contenedor inyecte el EM por usted.

Solo vi algunos ejemplos de dicho diseño. ¿Por qué? ¿Hay algún inconveniente serio?

Ya explicado.

Answer 2

Hay una cosa que quiero mencionar sobre el cambio de LockType de Singleton EJB. Si bien, en general, parece una buena idea, debe recordar que los recursos como EntityManger NO son seguros para subprocesos, por lo que se debe proporcionar un control de acceso concurrente apropiado. Puede anotar métodos que accedan a recursos que no sean seguros para subprocesos con @Lock (ESCRIBIR), pero si casi todos los métodos de interfaz de su EJB Singleton acceden a dichos recursos, tendrá casi la misma situación que con el bloqueado de escritura completa. La alternativa es usar Bean Concurrency Management con sincronización manual de grano fino, pero también es una decisión cuestionable.

Debido a esto, en general, prefiero los EJB sin estado a través de Singleton y el uso posterior en casos específicos.