JPA: Extendiendo el contexto de persistencia frente a entidades desprendimiento

Question

Parece que hay dos patrones para implementar las transacciones comerciales que abarcan varias peticiones HTTP con JPA:

1. entidad-manager-por-petición con entidades separadas
2. contexto de persistencia extendida

¿Cuáles son las ventajas respectivas de estos patrones? ¿Cuándo debería ser el preferido?

Hasta el momento, se me ocurrió:

• ampliados garantías contexto de persistencia ese objeto identidad es equivalente a la identidad de base de datos, lo que simplifica el modelo de programación y potencialmente disspelling la necesidad de implementar es igual para las entidades
• desenlazadas las entidades requieren menos memoria que un contexto de persistencia extendido, ya que el contexto de persistencia también tiene que almacenar el estado anterior de la entidad para la detección de cambios
• ya no hace referencia a las entidades separadas que se vuelven elegibles para la recolección de basura; los objetos persistentes primero deben separarse explícitamente

Sin embargo, al no tener ninguna experiencia práctica con JPA, estoy seguro de haber perdido algo de importancia, de ahí esta pregunta.

En caso de que importe: tenemos la intención de utilizar JPA 2.0 respaldado por Hibernate 3.6.

Editar: Nuestra tecnología es vista JSF 2.0, en un contenedor EJB 3.1, con CDI y, posiblemente, la costura 3.

Answer 1

Bueno, puede enumerar los retos de intentar utilizar contextos de persistencia prolongada en un entorno web. Algunas cosas también dependen de lo que sea su tecnología de visualización y si se trata de entidades vinculantes o de intermediarios de nivel de vista.

1. EntityManagers no son seguros para la rosca. No necesita una sesión por usuario. Necesita una por sesión de usuario por pestaña del navegador .
2. Cuando se produce una excepción en un EntityManager , se considera que es inválido y debe cerrarse y reemplazarse. Si planea , escriba sus propias extensiones de marco de trabajo para administrar el ciclo de vida extendido, la implementación de esto necesita a prueba de balas. Generalmente, en una configuración de EM por solicitud, la excepción va a algún tipo de página de error y y luego cargar la página siguiente crea un nuevo de todas formas, como siempre lo hubiera hecho .
3. La igualdad de objetos no va a ser 100% automágicamente segura. Como en el caso anterior, una excepción puede haber invalidado el contexto con el que se ha asociado un objeto previamente , por lo que uno obtenido ahora no será igual.Hacer esa asunción de también asume un alto nivel de habilidad extremadamente y comprensión de cómo funciona JPA y lo que hace el EM entre los desarrolladores de que lo usan. por ejemplo, al utilizar accidentalmente la combinación cuando no fue necesario, se devolverá un nuevo objeto que no satisfará == con su predecesor de campo . (Tratamiento de fusionarse como una 'actualización' SQL es una herramienta extremadamente común 'error' APP noobie particularmente porque es sólo un no-op mayoría de el tiempo para que se deslice pasado.)
4. Si está utilizando una vista tecnología que vincula POJO (por ejemplo, SpringMVC) y está planeando vincular los datos del formulario web directamente en sus Entidades, , se meterá en problemas rápidamente. Los cambios en una entidad adjunta serán persistentes en el siguiente flush/commit, independientemente de si se realizaron en una transacción o no. El error común es que el formulario web entra y enlaza algunos datos no válidos a una entidad, la validación falla y intenta devolver una pantalla para informar al usuario . La pantalla de error de construcción implica ejecutar una consulta. Consulta desencadena el enjuague/compromiso de persistencia contexto. Los cambios vinculados a la entidad adjunta se descargan a la base de datos, con la esperanza de causar una excepción SQL, pero puede que solo persista datos corruptos.

(4 Problema supuesto, también puede suceder con la sesión por la petición si la programación es descuidado, pero no estás obligado a trabajar activamente duro para evitarlo.)