Transacciones y gestión de caché

Hay una experiencia que todo desarrollador JPA vive algún día y que no se olvida: modificar una entidad sin llamar a ningún método de guardado y comprobar que la base de datos se ha actualizado. O, al contrario, llamar explícitamente a save() y ver que no ha cambiado nada. En ambos casos la causa es la misma: no sabe si el objeto que está manipulando está gestionado por el contexto de persistencia.

El contexto de persistencia es el corazón del funcionamiento de JPA. Es un registro en memoria, acotado por la transacción, que contiene todas las entidades cargadas o creadas durante esa transacción. Hibernate guarda además una fotografía de su estado en el momento de la carga. Al final de la transacción compara los objetos con su fotografía y emite un UPDATE por cada diferencia encontrada. Este mecanismo, llamado dirty checking (comprobación de cambios), explica que un simple setPrix() baste para escribir en la base de datos.

Esta elegancia tiene un precio: el momento en que se envía el SQL ya no lo determina su código, sino Hibernate. Las escrituras se acumulan y se envían en el último momento, en un orden que elige Hibernate. Comprender este aplazamiento es lo que separa al desarrollador que sufre @Transactional del que lo domina.