Transactions et gestion de cache

Il existe une expérience que tout développeur JPA fait un jour, et qui ne s'oublie pas : modifier une entité sans jamais appeler la moindre méthode de sauvegarde, et constater que la base a bien été mise à jour. À l'inverse, appeler save() explicitement et voir que rien n'a changé. Dans les deux cas, la cause est la même : vous ne savez pas si l'objet que vous manipulez est géré par le contexte de persistance.

Le contexte de persistance est le cœur du fonctionnement de JPA. C'est un registre en mémoire, borné par la transaction, qui contient toutes les entités chargées ou créées pendant cette transaction. Hibernate y garde aussi une photographie de leur état à l'instant du chargement. À la fin de la transaction, il compare les objets à leur photographie, et émet un UPDATE pour chaque différence trouvée. C'est ce mécanisme, appelé vérification sale, qui explique qu'un simple setPrix() suffise à écrire en base.

Cette élégance a un prix : le moment où le SQL part n'est plus déterminé par votre code, mais par Hibernate. Les écritures sont accumulées et envoyées au dernier moment, dans un ordre qu'Hibernate choisit. Comprendre ce report est ce qui sépare le développeur qui subit @Transactional de celui qui le maîtrise.