In the first part of this article, we learned how to improve the performance of our applications, replacing Tomcat with Undertow, which is a high-performance web server, in addition to enabling and configuring data compression, to reduce the size of HTTP responses that travel over the network.

Now, we will talk about how to improve Spring Boot application performance in the persistence part, but first we need to understand what JPA, Hibernate and Hikari.

JPA

JPA or Java Persistence API, which was later renamed to Jakarta Persistence, is a Java language standard that describes a common interface for data persistence frameworks

The

JPA specification defines object relational mapping internally, rather than relying on vendor-specific mapping implementations.

Hibernate

Hibernate is one of the ORM frameworks that makes the concrete implementation of the JPA specification. that is, if this specification describes the need for methods to persist, remove, update and fetch data, the person who will actually build these behaviors is Hibernate, as well as EclipseLink , which is another ORM.

Hikari

Hikari is a connection pooling framework, which is responsible for managing connections to the database, keeping them open so they can be reused, that is, it is a cache of connections for future requests, making access to the database faster and reducing the number of new connections to be created.

Configuring Hikari, JPA and Hibernate

A configuration that we can be performing to improve performance is the following:

Using application.yml:

spring: hikari: auto-commit: false connection-timeout: 250 max-lifetime: 600000 maximum-pool-size: 20 minimum-idle: 10 pool-name: master jpa: open-in-view: false show-sql: true hibernate: ddl-auto: none properties: hibernate.connection.provider_disables_autocommit: true hibernate.generate_statistics: true

spring:
  hikari:
    auto-commit: false
    connection-timeout: 250
    max-lifetime: 600000
    maximum-pool-size: 20
    minimum-idle: 10
    pool-name: master

  jpa:
    open-in-view: false
    show-sql: true
    hibernate:
      ddl-auto: none
    properties:
      hibernate.connection.provider_disables_autocommit: true
      hibernate.generate_statistics: true

Using application.properties:

spring.datasource.hikari.auto-commit=false spring.datasource.hikari.connection-timeout=50 spring.datasource.hikari.max-lifetime=600000 spring.datasource.hikari.maximum-pool-size=20 spring.datasource.hikari.minimum-idle=10 spring.datasource.hikari.pool-name=master spring.datasource.jpa.open-in-view=false spring.datasource.jpa.show-sql=true spring.datasource.jpa.hibernate.ddl-auto=none spring.jpa.properties.hibernate.generate_statistics=true spring.jpa.properties.hibernate.connection.provider_disables_autocommit=true

spring:
  hikari:
    auto-commit: false
    connection-timeout: 250
    max-lifetime: 600000
    maximum-pool-size: 20
    minimum-idle: 10
    pool-name: master

  jpa:
    open-in-view: false
    show-sql: true
    hibernate:
      ddl-auto: none
    properties:
      hibernate.connection.provider_disables_autocommit: true
      hibernate.generate_statistics: true

Now let's give a brief summary of the options:

Hikari

• spring.datasource.hikari.auto-commit: If false, every connection returned by

  connection pool will come with auto-commit disabled.

• spring.datasource.hikari.connection-timeout: Time, in milliseconds, that the client will wait for a connection from

  pool. It is preferable to set a short timeout to fail quickly and return an error message, rather than keeping the client waiting indefinitely.

• spring.datasource.hikari.max-lifetime: Maximum time a connection can remain active. Configuring this parameter is crucial to avoid failures due to problematic connections and increase security, as connections that have been active for a long time are more vulnerable to attacks.

• spring.datasource.hikari.maximum-pool-size: Maximum size of the

  pool, including idle and in-use connections, determining the maximum number of active connections to the database. If the pool reaches this limit and there are no idle connections, calls to getConnection() will block for up to connectionTimeout milliseconds before failing.

  Finding a suitable value is important, as many people think they will get great performance by setting it to 50, 70 or even 100. The ideal is to have a maximum of 20, which is the number of
  • threads in parallel using connections.
  The higher the value, the more difficult it will be for the database to manage these connections and most likely we will not be able to have enough
  • throughput to use all these connections.
  It is important to understand that from the point of view of
  • RDBMS (Relational Database Management System) it is difficult to maintain an open connection with itself, imagine n number of connections.
• spring.datasource.hikari.minimum-idle: Minimum number of connections the pool maintains when demand is low. The pool can reduce connections up to 10 and recreate them as needed. However, for maximum performance and better response to demand spikes, it is recommended not to set this value, allowing Hikari to function as a fixed-size pool. Default: same as spring.datasource.hikari.maximum-pool-size.

• spring.datasource.hikari.pool-name: User-defined name for the connection

  pool and appears primarily in registry management consoles and JMX to identify pools and their configurations.

JPA

• spring.datasource.jpa.open-in-view: When

  OSIV (Open Session In View) is enabled, a session is maintained throughout the request , even without the @Transactional annotation. This can cause performance problems, such as lack of application responses, as the session maintains the connection to the database until the end of the request.

• spring.datasource.jpa.show-sql: Displays the SQL log that is being executed in our application. We generally leave it enabled in development, but disabled in production.

• spring.datasource.jpa.hibernate.ddl-auto: Configures the behavior of

  Hibernate in relation to the database's schema. It can have the following values:

  none: Does nothing. We manually manage the bank's schema.
  validate: Validates the
  • schema of the database, but makes no changes. This is useful to ensure that the current schema agrees with the entities we have mapped.
  update: Updates the
  • schema of the database to reflect changes to the entities.
  create: Creates the
  • schema of the database. If the schema already exists, it will remove and create it again.
  create-drop: Creates the
  • schema from the database and, when the application ends, removes the schema. Useful for testing, where we want a clean database for each test.
• spring.jpa.properties.hibernate.generate_statistics: Serves to collect detailed information about Hibernate, such as query execution times, number of queries executed, and other metrics.

• spring.jpa.properties.hibernate.connection.provider_disables_autocommit: Informs

  Hibernate that we have disabled auto-commit of providers (PostgreSQL, MySQL, etc). This impacts performance because Hibernate will need to get a connection from the pool to know whether or not auto-commit is enabled or not , for every transaction he makes.

With this, we close the second part of the article. Not all the settings present were about performance, but the ones that really impact are the

Hikari settings like auto-commit and pool size , those of JPA and Hibernate like OSIV (Open Session In View) and inform that we have disabled auto-commit of providers.

In the next part we will talk about exceptions and how they can be configured, to save resources from the

JVM (Java Virtual Machine).

References:

https://en.wikipedia.org/wiki/Jakarta_Persistence
https://www.ibm.com/docs/pt-br/was/8.5.5?topic=SSEQTP_8.5.5/com.ibm.websphere.nd.multiplatform.doc/ae/cejb_persistence.htm
https://github.com/brettwooldridge/HikariCP
https://github.com/corona-warn-app/cwa-server/issues/556
https://medium.com/@rafaelralf90/open-session-in-view-is-evil-fd9a21645f8e