High-Performance Java Persistence – Chapter 8 – Why JPA and Hibernate matter
Imagine having a tool that can automatically detect JPA and Hibernate performance issues. Wouldn’t that be just awesome?
Well, Hypersistence Optimizer is that tool! And it works with Spring Boot, Spring Framework, Jakarta EE, Java EE, Quarkus, or Play Framework.
So, enjoy spending your time on the things you love rather than fixing performance issues in your production system on a Saturday night!
Second part, Chapter 8
Now that the first part of my book is published, it’s time to focus on the second part, which covers both JPA and Hibernate.
From now on, every new chapter is going to be released right after it’s completed, so the reader doesn’t have to wait for the whole part to be finished to get access to new chapters.
Table of content
This chapter aims to remind the reader why Hibernate has its place in high-performance data access, and the table of contents looks like this:
8. Why JPA and Hibernate matter 8.1 The impedance mismatch 8.2 JPA vs Hibernate 8.3 Schema ownership 8.4 Write-based optimizations 8.5 Read-based optimizations 8.6 Wrap-up
Chapter summary
In this chapter, you will learn that the object-relation impedance mismatch is inevitable when building an enterprise system on top of an OOP language.
JPA can reduce this gap, but only when used properly.
You will also learn that there are two schemas that need to stay in sync at all times: the Domain Model Entity hierarchy and the database schema. If the business logic drives the application evolution, the database system owns both the data and the schema itself, and the Domain Model must adapt to this relational model.
Another interesting topic is the fear of portability which might lead to discarding high-performance related features of both the underlying database system or the data access framework. As explained, portability doesn’t imply reducing access to common features only. One can achieve portability using feature specialization as well.
Hibernate is great for writing data. It comes with a transnational write-behind cache that can delay modifying statements from acquiring locks early. It can provide transparent batching and a solid base for implementing application-level concurrency control mechanisms.
When reading data, the application developer must take into consideration the purpose of the data being fetched. Entities are great for synchronizing changes, while projections are better suited for read-only views.
