Introduction The Persistence Context acts as a transactional-write behind cache for the incoming entity state transitions, and all changes are synchronized with the database during flushing. Although both the Hibernate Session and the JPA EntityManager define a flush() method to manually trigger this process, it’s much more convenient to let Hibernate manage the Persistence Context flushing. Unfortunately, there’s is a major difference between how JPA and Hibernate define the automatic flushing mechanism.
Introduction In my previous article I described the Hibernate automatic dirty checking mechanism. While you should always prefer it, there might be times when you want to add your own custom dirtiness detection strategy. Custom dirty checking strategies Hibernate offers the following customization mechanisms: Hibernate Interceptor#findDirty() CustomEntityDirtinessStrategy
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… Read More
Introduction Now that I described the the basics of JPA and Hibernate flush strategies, I can continue unraveling the surprising behavior of Hibernate’s AUTO flush mode. Not all queries trigger a Session flush Many would assume that Hibernate always flushes the Session before any executing query. While this might have been a more intuitive approach, and probably closer to the JPA’s AUTO FlushModeType, Hibernate tries to optimize that. If the currently executed query is not going to hit the pending SQL INSERT/UPDATE/DELETE statements then the flush is not strictly required. As stated… Read More
Introduction In my previous post I introduced the entity state transitions Object-relational mapping paradigm. All managed entity state transitions are translated to associated database statements when the current Persistence Context gets flushed. Hibernate’s flush behavior is not always as obvious as one might think. Write-behind Hibernate tries to defer the Persistence Context flushing up until the last possible moment. This strategy has been traditionally known as transactional write-behind. The write-behind is more related to Hibernate flushing rather than any logical or physical transaction. During a transaction, the flush may occur multiple times…. Read More