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”
The JDBC API has always been cumbersome and error-prone and I’ve never been too fond of using it. The first major improvement was brought by the Spring JDBC framework which simply revitalized the JDBC usage with its JdbcTemplate or the SqlFunction classes, to name a few. But Spring JDBC doesn’t address the shortcoming of using string function or input parameters names and this opened the door for type-safe SQL wrappers such as jOOQ.
JOOQ is the next major step towards a better JDBC API and ever since I started using it I knew there was no turning back. JOOQ became my number one choice for building dynamic queries and recently it became my standard SQL function wrapper.
Continue reading “JOOQ Facts: SQL functions made easy”