This blog article is part of a “series of blog articles” about common pitfalls using JPA and ways to avoid them. In this article, we describe issues with using null parameter values.Continue reading
Recently we encountered some severe performance problems in one of our projects. Some SQL queries were very slow.
A certain query took over 6 seconds to finish in Azure’s Postgres service and about 350ms locally on my laptop. Both are unacceptable.
I don’t know much more than the postgres basics and the project was in all parts relevant here more or less new to me. But let me show you how I approach the unknown, what I learned and how I solved it.
By the way: The issue is a prime example of not spending more time on optimisation than what feels necessary at the time. So even though the initial code looks a bit dumb in hindsight I still consider this ok as the application was fast enough for over 2 years in production and as we later learned the issue was caused by some up to that point unprecedented data.
Now, let’s dive in!
Most of our Java-based web-applications store their data in a relational database such as Oracle, PostgreSQL, MySQL, MariaDB or MS SQLServer. The standard way to access and modify the data is using an object-relational mapping as specified by the Java Persistence API (JPA). Over the years JPA has become a mature specification and there are a couple of JPA implementations with strong support such as Hibernate, EclipseLink, OpenJPA and DataNucleus. However, day-to-day project experience demonstrates there are number of pitfalls you might run into when using JPA.
To avoid stumbling into the same pitfall again and again, we collected them with their solutions and presented these pairs of problems and solutions. This is a start of a series of blog articles each describing a pitfall and a way to circumvent it.