Part 2, Chapter 14 Every new chapter of my book is released right after it’s being completed, so the reader doesn’t have to wait for the whole part to be finished to get access to new material. Table of content This chapter explains how batch updates work in Hibernate. 14. Batching 14.1 Batching insert statements 14.2 Batching update statements 14.3 Batching delete statements
Introduction As previously explained, every SQL statement must be executed in the context of a database transaction. For modifying statements (e.g. INSERT, UPDATE, DELETE), row-level locks must be taken to ensure recoverability and avoid the data anomalies. Next, I’ll demonstrate what can happen when a database transaction is not properly ended.
Part 2, Chapter 13 Every new chapter of my book is released right after it’s being completed, so the reader doesn’t have to wait for the whole part to be finished to get access to new material. Table of content This chapter explains the inner-workings of the Hibernate Persistence Context implementation. 13. Flushing 13.1 Flush modes 13.2 Events and the action queue 13.2.1 Flush operation order 13.3 Dirty Checking 13.3.1 The default dirty checking mechanism 126.96.36.199 Controlling the Persistence Context size 13.3.2 Bytecode enhancement
Introduction Hibernate runs the automatic dirty checking mechanism during flush-time, and any managed entity state change is translated into an UPDATE SQL statement. The default dirty checking mechanism uses Java reflection and goes through every property of every managed entity. If the Persistence Context has few entities, this process might go unnoticed, but, if we’re dealing with many entities or the entities have many properties (e.g. a legacy database Domain Model mapping), then the reflection-based dirty checking might have an associated performance impact.