However, when running the test case above, you will see that Hibernate issues no UPDATE statement since the Event entity is marked with the @Immutable annotation.
The reason why Hibernate does not track @Immutabale entity modifications is because the entity is loaded in read-only mode, hence the detachedState or hydratedState is never stored in the currently running Persistence Context.
JPQL update queries
Prior to Hibernate 5.2.17, JPQL queries were not taking into consideration the @Immutable status of a given entity.
In Hibernate 5.2.17, a WARNING message is logged when we try to modify the Event entity via a JPQL bulk update statement. Therefore, when running the following JPQL update query:
WARN HHH000487: The query: [update Event set eventValue = :eventValue where id = :id] attempts to update an immutable entity: [Event]
Query:["update Event set event_value=? where id=?"], Params:[(10, 1)]
Although the UPDATE statement is generated, there is now a WARNING message printed in the log.
If logging a WARN log entry is not sufficient for you and you want to prevent such modifications,
you can provide the following Hibernate configuration property:
Writing JPA Criteria API queries is not very easy. The Codota IDE plugin can guide you on how to write such queries, therefore increasing your productivity.
For more details about how you can use Codota to speed up the process of writing Criteria API queries, check out this article.
Hibernate logs the following output:
-- HHH000487: The query: [update Event as generatedAlias0 set generatedAlias0.eventValue = :param0 where generatedAlias0.id=1L] attempts to update an immutable entity: [Event]
Query:["update Event set event_value=? where id=1"], Params:[(100)]
Based on my book, High-Performance Java Persistence, this workshop teaches you various data access performance optimizations from JDBC, to JPA, Hibernate and jOOQ for the major rational database systems (e.g. Oracle, SQL Server, MySQL and PostgreSQL).