Imagine having a tool that can automatically detect if you are using JPA and Hibernate properly.
Hypersistence Optimizer is that tool!
Introduction
The persistence context enqueues entity state transitions that get translated to database statements upon flushing. For managed entities, Hibernate can auto-detect incoming changes and schedule SQL UPDATES on our behalf. This mechanism is called automatic dirty checking.
The default dirty checking strategy
By default Hibernate checks all managed entity properties. Every time an entity is loaded, Hibernate makes an additional copy of all entity property values. At flush time, every managed entity property is matched against the loading-time snapshot value:
So the number of individual dirty checks is given by the following formula:
where
n = The number of managed entities
p = The number of properties of a given entity
Even if only one property of a single entity has ever changed, Hibernate will still check all managed entities. For a large number of managed entities, the default dirty checking mechanism may have a significant CPU and memory footprint. Since the initial entity snapshot is held separately, the persistence context requires twice as much memory as all managed entities would normally occupy.
Bytecode instrumentation
A more efficient approach would be to mark dirty properties upon value changing. Analogue to the original deep comparison strategy, it’s good practice to decouple the domain model structures from the change detection logic. The automatic entity change detection mechanism is a cross-cutting concern, that can be woven either at build-time or at runtime.
The entity class can be appended with bytecode level instructions implementing the automatic dirty checking mechanism.
Weaving types
The bytecode enhancement can happen at:
Build-time
After the hibernate entities are compiled, the build tool (e.g. ANT, Maven) will insert bytecode level instructions into each compiled entity class. Because the classes are enhanced at build-time, this process exhibits no extra runtime penalty. Testing can be done against enhanced class versions, so that the actual production code is validated before the project gets built.
Runtime
The runtime weaving can be done using:
A Java agent, doing bytecode enhancement upon entity class loading
If you enjoyed this article, I bet you are going to love my Book and Video Courses as well.
Hibernate 5 improvements
Hibernate 3 has been offering bytecode instrumentation through an ANT target but it never became mainstream and most Hibernate projects are still currently using the default deep comparison approach. Hibernate 5 has redesigned the bytecode enhancement mechanism, is more reliable than it used to be.
Thanks,I want to know why I never change the entities property, the dirty check is also running,When I use Spring saveAll fuction,he said the last transaction has a lot of collection, but they are old and I have not changed these entities properties ,so I want to know how to clear these copied entities or how can I banned the dirty check when auto flush?
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).
Thank Vlad, Would you like to tell me which page it is?
Check out the Flushing chapter.
Thanks,I want to know why I never change the entities property, the dirty check is also running,When I use Spring saveAll fuction,he said the last transaction has a lot of collection, but they are old and I have not changed these entities properties ,so I want to know how to clear these copied entities or how can I banned the dirty check when auto flush?
There are many options. Check out my High-Performance Java Persistence book for more details.
Thanks, meanwhile is there a good example of using bytecode instrumention?
Check out this article.