2014 – A year in review



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:


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:

Continue reading “2014 – A year in review”


A beginner’s guide to transaction isolation levels in enterprise Java


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 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”

EAGER fetching is a code smell


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.

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

Continue reading “EAGER fetching is a code smell”

How to prevent OptimisticLockException with Hibernate versionless optimistic locking


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.

Continue reading “How to prevent OptimisticLockException with Hibernate versionless optimistic locking”

Spring request-level memoization


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”