High-Performance Java Persistence by Vlad Mihalcea

Hi Vlad,

Tell me a little bit about yourself.

Hi, Petri. My name is Vlad Mihalcea, and I work as a Developer Advocate for the Hibernate project.

A lot of people might know because of your job as a Hibernate developer advocate,
but I know that you have been interested in writing robust data access code for a lot longer.
What is the thing that fascinates you about data access code?

I like everything data: Relational database systems (e.g. Oracle, SQL Sever, PostgreSQL, MySQL),
NewSQL (e.g. VoltDB), NoSQL (e.g. RocksDB), caching solutions (e.g. Infinispan, Hazelcast).

The data ecosystem is very diverse, making it a very attractive choice for a software engineer.

The reason why I decided to invest in data access performance tuning is because this can make the difference between a high-performance enterprise application and one that barely crawls.

What is the most common mistake developers do when they design and implement the data access layer of their applications?

I actually have a blog post, (14 High-Performance Java Persistence Tips), which illustrates some of the most common performance-related issues.

In my experience, the most common performance-related issue is fetching too much data when the current business use case only needs a subset instead.

Logging and monitoring are of paramount importance when it comes to performance tuning because data access patterns are constantly changing, being driven by the evolution of an enterprise system. In this context, one very common mistake is to avoid verifying what SQL statements are generated by the underlying JPA provider. The moment when you know what SQL statements are associated with a given entity mapping, you can better decide how the Domain Model should be designed.

Some time ago you finished your first book titled: "High-Performance Java Persistence". Why did you decide to write it, and what problem does it solve?

When it comes to data access, many problems stem from the software developers skill mismatch.
The vast majority of software developers have very good object-oriented programming skills,
while SQL and database skills are often overlooked.

For this reason, the Domain Model, and the business logic is often designed from an OOP perspective
while ignoring the data access patterns that happen behind the scenes.

That was exactly the reason I decided to write "High-Performance Java Persistence".

I have noticed that a lot of people are looking for alternative ways for implementing their repositories. What I mean is that people seem to be replacing ORMs with plain old JDBC. Do you have any thoughts about this?

It's all JDBC in the end. However, JDBC alone is not sufficient because, when you operate application-level transactions, you need application-level concurrency control mechanisms, and that's why Hibernate is a great choice for multi-request web flows.

ORMs and JPA are very good for writing data because changes are propagated automatically from entity state transitions. However, for reading data, native SQL is the way to go.

All in all, I think that mixing JPA with a query builder framework like jOOQ is the best combination for your data access layer.

Thank you for your time!

Thank You Vlad!