High-Performance Java Persistence Newsletter, Issue 33
Are you struggling with performance issues in your Spring, Jakarta EE, or Java EE application?
Imagine having a tool that could automatically detect performance issues in your JPA and Hibernate data access layer long before pushing a problematic change into production!
With the widespread adoption of AI agents generating code in a heartbeat, having such a tool that can watch your back and prevent performance issues during development, long before they affect production systems, can save your company a lot of money and make you a hero!
Hypersistence Optimizer is that tool, and it works with Spring Boot, Spring Framework, Jakarta EE, Java EE, Quarkus, Micronaut, or Play Framework.
So, rather than allowing performance issues to annoy your customers, you are better off preventing those issues using Hypersistence Optimizer and enjoying spending your time on the things that you love!
Introduction
Welcome to a new issue of the High-Performance Java Persistence Newsletter in which we share articles, videos, workshops, and StackOverflow answers that are very relevant to any developer who interacts with a database system using Java.
Articles
The pick of this edition is this article written by Connor McDonald about database indexing performance. Many devs believe that having tens of millions of records in a table is a lot of data. But, that’s not really the case. In his article, Connor builds a 2 billion rows table that’s indexed for three types of queries, and, because of indexing, all those queries run very fast. For instance, fetching 200k users for a given post took on average 50ms, and in the worst case, 371ms. Not bad for a 2 billion record table and a 40-years old database, right?
A very interesting read is this article that shows the overhead of various indexing options when using PostgreSQL. The article goes through simple indexes, multi-column indexes, partial indexes, and covering indexes as well.
Talking of indexes or lack thereof, this article explains that bad data access strategies can lead to hefty cloud bills. So, if you want to get good performance and lower your cloud bill, then you should optimize your data access layer based on your application-specific requirements.
If you’re using MySQL, then you should definitely read this article, which explains the memory overhead of using very large triggers.
Now, if you are curious what technology stack I’d choose when starting a new web application, then check out this article which explains the RevoGain software architecture.
Best Tweets
Here are the best tweets I posted since the last newsletter:
In software, legacy means it runs in production.
— Vlad Mihalcea (@vlad_mihalcea) November 7, 2021
Debugging in production pic.twitter.com/xvZ8UN9lR5
— Vlad Mihalcea (@vlad_mihalcea) November 23, 2021
Modern software architectures pic.twitter.com/DSoVMGGEdS
— Vlad Mihalcea (@vlad_mihalcea) November 20, 2021
Knowing your IDE very well is more important than the IDE itself.
— Vlad Mihalcea (@vlad_mihalcea) November 25, 2021
In software, minimalism works best.
— Vlad Mihalcea (@vlad_mihalcea) November 26, 2021
Project Releases
A very highly expected upgrade came from Amazon Aurora who added support for MySQL 8. Check out the release notes for more details about your upgrade options.
PostgreSQL 14.1 has been released, providing several bug fixes for issues reported for the 14.0 version.
The H2 database has reached a very important milestone and released the 2.0 version.
The Hibernate team released the 1.1 version of Hibernate Reactive, which aims to provide a reactive data access alternative to the JDBC-based Hibernate ORM.
Get in touch with my latest articles!
StackOverflow Answers
The following StackOverflow answers have been trending over the past two weeks:
- How to inject multiple JPA EntityManager (persistence units) when using Spring
- Hibernate Annotations – Which is better, field or property access?
- How to clear a JPA collection and add new items
- Java encoding issues after upgrading to Java 17 using the Microsoft OpenJDK
- Why use your application-level cache if the database already provides caching?
