In this article, I’m going to explain how the Spring read-only transaction Hibernate optimization works.
After taking a look at what the Spring framework does when enabling the
readOnly attribute on the
@Transactional annotation, I realized that only the Hibernate flush mode is set to
FlushType.MANUAL without propagating the read-only flag further to the Hibernate
So, in the true spirit of open-source software developer, I decided it’s time to make a change.
Continue reading “Spring read-only transaction Hibernate optimization”
Hibernate comes with many additions to the standard JPA specification. One such example is the
@GeneratorType annotation which allows you to customize the way a given entity property value is automatically generated.
If you’re using Spring Data, you can simply use the
@LastModifiedBy annotations and the annotated entity properties are going to be populated with the currently logged user.
If you’re not using Spring Data, then you can easily emulate the same behavior using the Hibernate-specific
@GeneratorType annotation and the
ValueGenerator callback mechanism.
Continue reading “How to emulate @CreatedBy and @LastModifiedBy from Spring Data using the @GeneratorType Hibernate annotation”
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.
Continue reading “A beginner’s guide to transaction isolation levels in enterprise Java”
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 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.
Continue reading “Spring request-level memoization”
I like to make use of the builder pattern whenever an object has both mandatory and optional properties. But building objects is usually the Spring framework responsibility, so let’s see how you can employ it using both Java and XML-based Spring configurations.
Continue reading “The Builder pattern and the Spring framework”