Imagine having a tool that can automatically detect JPA and Hibernate performance issues.
Hypersistence Optimizer is that tool!
The JPA specification is like a Java interface, However, when it comes to performance, implementation details matter a lot. That’s why, even if you use the JPA standard, you still need to know how the underlying provider implements the standard specification.
For instance, if we take this tweet from Gareth Western:
b.id AS id1_0_,
b.isbn AS isbn2_0_,
b.name AS name3_0_
b.name = ?
The literal is gone! Instead, we now got a PreparedStatement bind parameter.
Now, depending on the use case, you either want to use inlined literal values or substitute them with bind parameters. The advantage of using bind parameters is that the query Parse Tree and the Execution Plan (e.g. Oracle, SQL Server) could be cached.
However, sometimes caching the Execution Plan can cause more harm than good, especially if the literal values are skewed or there is a lot of contention on the Execution Plan Cache.
For this purpose, the HHH-9576 Jira issue was created.
Confguring the literal handling mode
Since Hibernate 5.2.12, you can use the LiteralHandlingMode to define the strategy used for handling literals in Criteria API queries. This enumeration takes three values:
AUTO, which works exactly as you’ve just seen. Numeric values are inlined while String-based ones are substituted with bind parameters.
INLINE, which will inline both numeric and String-based values.
BIND, which will substitute both numeric and String-based literals with bind parameters.
Specifying the expected Criteria API literal handling mode is actually a very nice enhancement. While the default AUTO mode might work just fine for many data access layers, in case you need to change the way literals are being handled, just provide the LiteralHandlingMode strategy you want to use, and Hibernate will switch to using that one instead.