Transações e gerenciamento de cache

Todo desenvolvedor JPA passa um dia por uma experiência que não se esquece: modificar uma entidade sem nunca chamar qualquer método de salvamento e constatar que o banco foi atualizado mesmo assim. Ou, ao contrário, chamar save() explicitamente e ver que nada mudou. Nos dois casos, a causa é a mesma: você não sabe se o objeto que está manipulando é gerenciado pelo contexto de persistência.

O contexto de persistência é o coração do funcionamento do JPA. É um registro em memória, delimitado pela transação, que contém todas as entidades carregadas ou criadas durante essa transação. O Hibernate também guarda ali uma fotografia do estado delas no momento do carregamento. No fim da transação, ele compara os objetos com suas fotografias e emite um UPDATE para cada diferença encontrada. Esse mecanismo, chamado de dirty checking, explica por que um simples setPrix() basta para escrever no banco.

Essa elegância tem um preço: o momento em que o SQL é enviado deixa de ser determinado pelo seu código e passa a ser determinado pelo Hibernate. As escritas são acumuladas e enviadas no último instante, em uma ordem que o Hibernate escolhe. Entender esse adiamento é o que separa o desenvolvedor que sofre com o @Transactional daquele que o domina.