2014 – A year in review
Imagine having a tool that can automatically detect JPA and Hibernate performance issues. Wouldn’t that be just awesome?
Well, Hypersistence Optimizer is that tool! And it works with Spring Boot, Spring Framework, Jakarta EE, Java EE, Quarkus, or Play Framework.
So, enjoy spending your time on the things you love rather than fixing performance issues in your production system on a Saturday night!
Retrospective
January
In the beginning of 2014, I took the initial version of my time series MongoDB aggregation example and pass it through a multistage optimization process, from indexing to advanced data-modelling:
- MongoDB time series: Introducing the aggregation framework
- A beginner’s guide to MongoDB performance turbocharging
- MongoDB and the fine art of data modelling
February
In February, I starting developing FlexyPool, the ultimate connection pool sizing utility. This was a great opportunity to dig into Queuing Theory and the following articles capture some of my findings:
A beginner’s guide to transaction isolation levels in enterprise Java
Imagine having a tool that can automatically detect JPA and Hibernate performance issues. Wouldn’t that be just awesome?
Well, Hypersistence Optimizer is that tool! And it works with Spring Boot, Spring Framework, Jakarta EE, Java EE, Quarkus, or Play Framework.
So, enjoy spending your time on the things you love rather than fixing performance issues in your production system on a Saturday night!
Introduction
A relational database strong consistency model is based on ACID transaction properties. In this post we are going to unravel the reasons behind using different transaction isolation levels and various configuration patterns for both resource local and JTA transactions.
Isolation and consistency
In a relational database system, atomicity and durability are strict properties, while consistency and isolation are more or less configurable. We cannot even separate consistency from isolation as these two properties are always related.
The lower the isolation level, the less consistent the system will get. From the least to the most consistent, there are four isolation levels:
- READ UNCOMMITTED
- READ COMMITTED (protecting against dirty reads)
- REPEATABLE READ (protecting against dirty and non-repeatable reads)
- SERIALIZABLE (protecting against dirty, non-repeatable reads and phantom reads)
Although the most consistent SERIALIZABLE isolation level would be the safest choice, most databases default to READ COMMITTED instead. According to Amdahl’s law, to accommodate more concurrent transactions, we have to reduce the serial fraction of our data processing. The shorter the lock acquisition interval, the more requests a database can process.
JPA and Hibernate FetchType EAGER is a code smell
Imagine having a tool that can automatically detect JPA and Hibernate performance issues. Wouldn’t that be just awesome?
Well, Hypersistence Optimizer is that tool! And it works with Spring Boot, Spring Framework, Jakarta EE, Java EE, Quarkus, or Play Framework.
So, enjoy spending your time on the things you love rather than fixing performance issues in your production system on a Saturday night!
Introduction
Hibernate fetching strategies can really make a difference between an application that barely crawls and a highly responsive one. In this post, I’ll explain why you should prefer query-based fetching instead of global fetch plans.
Had this problem this morning fixed from stackoverflow than found this. Thx Vlad Mihalcea for a concise explanation !!!
— Gal Levinshtein (@gkodkod) September 17, 2018
EAGER fetching is a code smell when using #JPA and @Hibernate @vlad_mihalcea https://t.co/7NqKH0S9oG
Fetching 101
Hibernate defines four association retrieving strategies:
| Fetching Strategy | Description |
|---|---|
| Join | The association is OUTER JOINED in the original SELECT statement |
| Select | An additional SELECT statement is used to retrieve the associated entity(entities) |
| Subselect | An additional SELECT statement is used to retrieve the whole associated collection. This mode is meant for to-many associations |
| Batch | An additional number of SELECT statements is used to retrieve the whole associated collection. Each additional SELECT will retrieve a fixed number of associated entities. This mode is meant for to-many associations |
How to prevent OptimisticLockException with Hibernate versionless optimistic locking
Imagine having a tool that can automatically detect JPA and Hibernate performance issues. Wouldn’t that be just awesome?
Well, Hypersistence Optimizer is that tool! And it works with Spring Boot, Spring Framework, Jakarta EE, Java EE, Quarkus, or Play Framework.
So, enjoy spending your time on the things you love rather than fixing performance issues in your production system on a Saturday night!
Introduction
In my previous post I demonstrated how you can scale optimistic locking through write-concerns splitting.
Version-less optimistic locking is one lesser-known Hibernate feature. In this post, I’ll explain both the good and the bad parts of this approach.
Version-less optimistic locking
Optimistic locking is commonly associated with a logical or physical clocking sequence, for both performance and consistency reasons. The clocking sequence points to an absolute entity state version for all entity state transitions.
To support legacy database schema optimistic locking, Hibernate added a version-less concurrency control mechanism. To enable this feature you have to configure your entities with the @OptimisticLocking annotation that takes the following parameters:
| Optimistic Locking Type | Description |
|---|---|
| ALL | All entity properties are going to be used to verify the entity version |
| DIRTY | Only current dirty properties are going to be used to verify the entity version |
| NONE | Disables optimistic locking |
| VERSION | Surrogate version column optimistic locking |
For version-less optimistic locking, you need to choose ALL or DIRTY.
Spring request-level memoization
Imagine having a tool that can automatically detect JPA and Hibernate performance issues. Wouldn’t that be just awesome?
Well, Hypersistence Optimizer is that tool! And it works with Spring Boot, Spring Framework, Jakarta EE, Java EE, Quarkus, or Play Framework.
So, enjoy spending your time on the things you love rather than fixing performance issues in your production system on a Saturday night!
Introduction
Memoization is a method-level caching technique for speeding-up consecutive invocations.
This post will demonstrate how you can achieve request-level repeatable reads for any data source, using Spring AOP only.
Spring Caching
Spring offers a very useful caching abstracting, allowing you do decouple the application logic from the caching implementation details.
Spring Caching uses an application-level scope, so for a request-only memoization we need to take a DIY approach.
Java Performance Workshop with Peter Lawrey
Imagine having a tool that can automatically detect JPA and Hibernate performance issues. Wouldn’t that be just awesome?
Well, Hypersistence Optimizer is that tool! And it works with Spring Boot, Spring Framework, Jakarta EE, Java EE, Quarkus, or Play Framework.
So, enjoy spending your time on the things you love rather than fixing performance issues in your production system on a Saturday night!
Peter Lawrey at IT Days
I’ve just come back from a Java Performance Workshop held by Peter Lawrey at Cluj-Napoca IT Days.
Peter Lawrey is a well-known Java StackOverflow user and the creator of Java Chronicle open-source library.
Of Java and low latency
Little’s Law defines concurrency as:
To increase throughput we can either:
- increase server resources (scaling vertically or horizontally)
- decrease latency (improve performance)
While enterprise applications are usually designed for scaling, trading systems focus on lowering latencies.
As surprising as it may sound, most trading systems, I’ve heard of, are actually written in Java. Java automatic memory management is a double-edged sword, since it trades simplicity for flexibility.
A low latency system worse nightmare is a stop-of-the-world process, like a garbage collector major collection. So in order to avoid such situations, you must go off-heap.
How to address the OptimisticLockException in JPA and Hibernate
Imagine having a tool that can automatically detect JPA and Hibernate performance issues. Wouldn’t that be just awesome?
Well, Hypersistence Optimizer is that tool! And it works with Spring Boot, Spring Framework, Jakarta EE, Java EE, Quarkus, or Play Framework.
So, enjoy spending your time on the things you love rather than fixing performance issues in your production system on a Saturday night!
Introduction
Application-level repeatable reads are suitable for preventing lost updates in web conversations. Enabling entity-level optimistic locking is fairly easy. You just have to mark one logical-clock property (usually an integer counter) with the JPA @Version annotation and Hibernate takes care of the rest.
The catch
Optimistic locking discards all incoming changes that are relative to an older entity version. But everything has a cost and optimistic locking makes no difference.
The optimistic concurrency control mechanism takes an all-or-nothing approach even for non-overlapping changes. If two concurrent transactions are changing distinct entity property subsets, then there’s no risk of losing updates.
Two concurrent updates, starting from the same entity version are always going to collide. It’s only the first update that’s going to succeed, the second one failing with an optimistic locking exception. This strict policy acts as if all changes are overlapping. For highly concurrent write scenarios, this single-version check strategy can lead to a large number of roll-backed updates.
Hibernate collections optimistic locking
Imagine having a tool that can automatically detect JPA and Hibernate performance issues. Wouldn’t that be just awesome?
Well, Hypersistence Optimizer is that tool! And it works with Spring Boot, Spring Framework, Jakarta EE, Java EE, Quarkus, or Play Framework.
So, enjoy spending your time on the things you love rather than fixing performance issues in your production system on a Saturday night!
Introduction
Hibernate provides an optimistic locking mechanism to prevent lost updates even for long-conversations. In conjunction with an entity storage, spanning over multiple user requests (extended persistence context or detached entities) Hibernate can guarantee application-level repeatable-reads.
The dirty checking mechanism detects entity state changes and increments the entity version. While basic property changes are always taken into consideration, Hibernate collections are more subtle in this regard.
Owned vs Inverse collections
In relational databases, two records are associated with a foreign key reference. In this relationship, the referenced record is the parent while the referencing row (the foreign key side) is the child. A non-null foreign key may only reference an existing parent record.
In the Object-oriented space, this association can be represented in both directions. We can have a many-to-one reference from a child to parent and the parent can also have a one-to-many children collection.
Because both sides could potentially control the database foreign key state, we must ensure that only one side is the owner of this association. Only the owning side state changes are propagated to the database. The non-owning side has been traditionally referred as the inverse side.
Next, I’ll describe the most common ways of modeling this association.
How does Hibernate guarantee application-level repeatable reads
Imagine having a tool that can automatically detect JPA and Hibernate performance issues. Wouldn’t that be just awesome?
Well, Hypersistence Optimizer is that tool! And it works with Spring Boot, Spring Framework, Jakarta EE, Java EE, Quarkus, or Play Framework.
So, enjoy spending your time on the things you love rather than fixing performance issues in your production system on a Saturday night!
Introduction
In my previous post I described how application-level transactions offer a suitable concurrency control mechanism for long conversations.
All entities are loaded within the context of a Hibernate Session, acting as a transactional write-behind cache.
A Hibernate persistence context can hold one and only one reference to a given entity. The first level cache guarantees session-level repeatable reads.
If the conversation spans over multiple requests we can have application-level repeatable reads. Long conversations are inherently stateful so we can opt for detached objects or long persistence contexts. But application-level repeatable reads require an application-level concurrency control strategy such as optimistic locking.
The catch
But this behavior may prove unexpected at times.
