JPA: ¿Cómo sincronizo el contexto de persistencia con el resultado de la actualización masiva o eliminación?

Question

Hay una afirmación en el ejb-3_0-fr-spec-persistence.pdf que dice

El contexto de persistencia no está sincronizado con el resultado de la actualización masiva o eliminar

Así que si yo hacer una query.executeUpdate que borre filas de una tabla. Esas mismas filas todavía existen en otras entidades de una a muchas colecciones. Cuando reinicio la aplicación, veo que las entidades ficticias ahora se eliminan de la colección.

¿Existe una forma (bonita \ simple \ genérica) de sincronizar la memoria caché de JPA con el resultado de una actualización masiva \ eliminar?

BTW. Estoy usando EclipseLink, versión: Eclipse Persistence Services - 1.1.0.r3634.

Gracias,

Phil.

Answer 1

Tienes que tener cuidado con la forma en que usas la palabra "caché" porque puede significar cosas diferentes.

La frase resaltada habla sobre el contexto de persistencia, que se puede considerar como "caché de primer nivel". Con el fin de actualizarlo con los últimos cambios de la base de datos, puede:

1. llamada EntityManager.refresh() para actualizar el estado de una sola entidad .
2. O descarte la instancia del administrador de entidades por completo (después de lavar/borrar los cambios según corresponda) y obtenga una nueva de la fábrica del administrador de entidades. Todas las entidades que cargue desde esta nueva instancia se cargarán desde la base de datos y, por lo tanto, contendrán los últimos cambios.

Luego también puede haber un "caché de segundo nivel" que no está vinculado a un administrador de entidades en particular. Puede actualizarlo (o, mejor dicho, borrarlo y dejar que se vuelva a llenar él mismo) usando su propia API (difiere entre los proveedores de caché).

Answer 2

El contexto de persistencia no se actualiza para reflejar los resultados de las operaciones de actualización y eliminación. Si utiliza un contexto de persistencia con ámbito de transacción, debe ejecutar la operación masiva en una transacción por sí mismo o ser la primera operación en la transacción (consulte Introducción a las transacciones de EclipseLink). Esto se debe a que cualquier entidad gestionada de forma activa por el contexto de persistencia seguirá sin tener conocimiento de los cambios reales que se producen en el nivel de la base de datos.

Fell cómodo para mí tocar aquí en http://puspendu.wordpress.com/2010/12/22/sync-jpa-database-multiple-application/

Answer 3

Así es como se borran los datos almacenados en caché.

entityManager.getEntityManagerFactory().getCache().evictAll(); 

Answer 4

La primera caché de nivel (EntityManager/transacción) tendrá que ser renovado o limpiado manualmente. Puede actualizar los objetos, invocar clear() u obtener un nuevo EntityManager.

La memoria caché de segundo nivel (caché compartido) debe anularse automáticamente cuando se confirma la transacción. Si no es por alguna razón, puede usar la API de caché JPA o la API JpaCache de EclipseLink para desalojar o invalidar los objetos, o puede actualizarlos.

---