How to prevent lost updates in long conversations
Introduction All database statements are executed within the context of a physical transaction, even when we don’t explicitly declare transaction boundaries (BEGIN/COMMIT/ROLLBACK). Data integrity is enforced by the ACID properties of database transactions. Logical vs Physical transactions A logical transaction is an application-level unit of work that may span over multiple physical (database) transactions. Holding the database connection open throughout several user requests, including user think time, is definitely an anti-pattern. A database server can accommodate a limited number of physical connections, and often those are reused by using connection pooling. Holding… Read More
A beginner’s guide to database locking and the lost update phenomena
Introduction A database is highly concurrent system. There’s always a chance of update conflicts, like when two concurring transactions try to update the same record. If there would be only one database transaction at any time then all operations would be executed sequentially. The challenge comes when multiple transactions try to update the same database rows as we still have to ensure consistent data state transitions. The SQL standard defines three consistency anomalies (phenomena): Dirty reads, prevented by Read Committed, Repeatable Read and Serializable isolation levels Non-repeatable read, prevented by Repeatable Read… Read More
How does the bytecode enhancement dirty checking mechanism work in Hibernate 4.3
Introduction Now that you know the basics of Hibernate dirty checking, we can dig into enhanced dirty checking mechanisms. While the default graph-traversal algorithm might be sufficient for most use-cases, there might be times when you need an optimized dirty checking algorithm and instrumentation is much more convenient than building your own custom strategy. Using Ant Hibernate Tools Traditionally, The Hibernate Tools have been focused on Ant and Eclipse. Bytecode instrumentation has been possible since Hibernate 3, but it required an Ant task to run the CGLIB or Javassist bytecode enhancement routines.
How to customize Hibernate dirty checking 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
The anatomy of Hibernate dirty checking mechanism
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
How does AUTO flush strategy work in JPA and Hibernate
Introduction The Hibernate AUTO flush mode behaves differently whether you are bootstrapping Hibernate via JPA or using the stand-alone mechanism. When using JPA, the AUTO flush mode causes all queries (JPQL, Criteria API, and native SQL) to trigger a flush prior to the query execution. However, this is not the case when bootstrapping Hibernate using the native API. 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… Read More
A beginner’s guide to flush strategies in JPA and Hibernate
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
A beginner’s guide to entity state transitions with JPA and Hibernate
Introduction Hibernate shifts the developer mindset from SQL statements to entity state transitions. Once an entity is actively managed by Hibernate, all changes are going to be automatically propagated to the database. Manipulating domain model entities (along with their associations) is much easier than writing and maintaining SQL statements. Without an ORM tool, adding a new column requires modifying all associated INSERT ir UPDATE statements. But Hibernate is no silver bullet either. Hibernate doesn’t free us from ever worrying about the actual executed SQL statements. Controlling Hibernate is not as straightforward as… Read More
Hibernate pooled and pooled-lo identifier generators
Introduction In this post, we’ll uncover a sequence identifier generator combining identifier assignment efficiency and interoperability with other external systems (concurrently accessing the underlying database system). Traditionally there have been two sequence identifier strategies to choose from: sequence and seqhilo. The sequence identifier, always hitting the database for every new value assignment. Even with database sequence preallocation, we have a significant database round-trip cost. The seqhilo identifier, using the hilo algorithm. This generator calculates some identifier values in-memory, therefore reducing the database round-trip calls. The problem with this optimization technique is that… Read More
A beginner’s guide to Hibernate enhanced identifier generators
JPA identifier generators JPA defines the following identifier strategies: Strategy Description AUTO The persistence provider picks the most appropriate identifier strategy supported by the underlying database IDENTITY Identifiers are assigned by a database IDENTITY column SEQUENCE The persistence provider uses a database sequence for generating identifiers TABLE The persistence provider uses a separate database table to emulate a sequence object In my previous post I exampled the pros and cons of all these surrogate identifier strategies.
