Spring read-only transaction Hibernate optimization

Introduction

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 Session.

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”

How to emulate @CreatedBy and @LastModifiedBy from Spring Data using the @GeneratorType Hibernate annotation

Introduction

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 @CreatedBy and @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 beginner’s guide to transaction isolation levels in enterprise Java

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.

Continue reading “A beginner’s guide to transaction isolation levels in enterprise Java”

Spring request-level memoization

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.

Continue reading “Spring request-level memoization”