Imagine having a tool that can automatically detect JPA and Hibernate performance issues. Hypersistence Optimizer is that tool!
Although there is an SQL Standard, every relational database is ultimately unique, and you need to adjust your data access layer so that you get the most out of the relational database in use.
In this article, we are going to see what you can do to boost up performance when using MySQL with JPA and Hibernate.
Every entity needs to have an identifier which uniquely identifies the table record associated with this entity. JPA and Hibernate allow you to automatically generate entity identifiers based on three different strategies:
As I explained in this article, The TABLE identifier strategy does not scale when increasing the number of database connections. More, even for one database connection, the identifier generation response time is 10 times greater than when using IDENTITY or SEQUENCE.
If you are using the AUTO GenerationType:
@Id @GeneratedValue(strategy = GenerationType.AUTO) private Long id;
Hibernate 5 is going to fall back to using the TABLE generator, which is bad for performance.
As I explained in this article, you can easily fix this issue with the following mapping:
@Id @GeneratedValue(strategy= GenerationType.AUTO, generator="native") @GenericGenerator(name = "native", strategy = "native") private Long id;
The native generator will pick IDENTITY instead of TABLE.
Neither MySQL 5.7 or 8.0 support SEQUENCE objects, you need to use IDENTITY. However, as I explained in this article, the IDENTITY generator prevents Hibernate from using JDBC batch inserts.
JDBC batch updates and deletes are not affected, only the INSERT statements cannot be batched because, by the time the Persistence Context is flushed, the INSERT statements were already executed so that Hibernate knows what entity identifier to assign to the entities that got persisted.
If you want to fix this issue, you have to execute the JDBC batch inserts with a different framework, like jOOQ.
MySQL and MariaDB are notoriously slow when having to discard the database schema and recreating it every time a new integration test is about to run. However, you can easily address this issue with the help of Docker and tmpfs.
As I explained in this article, by mapping the data folder in-memory, integration tests are going to run almost as fast as with an in-memory database like H2 or HSQLDB.
Even when you are using a RDBMS, there are many times when you want to store non-structured data:
Although not supported natively, you can easily map a Java object to a JSON column. You can even map the JSON column type to a Jackson JsonNode.
More, you don’ even have to write these custom types, you can just grab them from Maven Central:
<dependency>
<groupId>com.vladmihalcea</groupId>
<artifactId>hibernate-types-52</artifactId>
<version>${hibernate-types.version}</version>
</dependency>
Cool, right?
When processing large volumes of data, it’s not very efficient to move all this data in and out of the database. It’s much better to do the processing on the database side by calling a Stored Procedure.
For more details, check out this article about how you can call a MySQL Stored Procedure with JPA and Hibernate.
SQL streaming makes sense for two-tier applications. If you want to do ResultSet streaming, you have to pay attention to the JDBC Driver as well. On MySQL, to use a database cursor, you have to options:
Statement fetch size to Integer.MIN_VALUE,useCursorFetch connection property to true and then you can set the Statement fetch size to a positive integer valueHowever, for web-based applications, pagination is much more suitable. JPA 2.2 even introduces support for Java 1.8 Stream methods, but the Execution Plan might not be as efficient as when using SQL-level pagination.
Although you might that, since Hibernate uses PreparedStatements by default, all statements are executed like this:
In reality, they are executed more like this:
As I explained in this article unless you set the useServerPrepStmts MySQL JDBC Driver property, PreparedStatements are going to be emulated at the JDBC Driver level to save one extra database roundtrip.
In a relational database, every statement is executed within a given database transaction. Therefore, transactions are not optional.
However, you should always end the current running transaction, either through a commit or a rollback. Forgetting to end transactions can lead to locks being held for a very long time, as well as preventing the MVCC cleanup process from reclaiming old tuples or index entries that are no longer needed.
There are two very complicated things in programming:
To address the second problem, it’s better to save all timestamps in UTC timezone. However, prior to the MySQL Connector/J 8.0, you also needed to set the useLegacyDatetimeCode JDBC Driver configuration property to false. Since MySQL Connector/J 8.0, you don’t need to provide this property.
Online Workshops
If you enjoyed this article, I bet you are going to love my upcoming Online Workshops.
- Transactions and Concurrency Control Patterns (3 hours) on the 10th of February
- High-Performance Java Persistence (16 hours) starting on the 1st of March in collaboration with Bouvet
As you can see, there are many things to keep in mind when using MySQL with JPA and Hibernate. Since MySQL is one of the most deployed RDBMS, being used by the vast majority of web applications, it’s very useful to know all these tips and adjust your data access layer to get the most out of it.
