Java Persistence API (JPA)

The student will learn:

At the conclusion of this lecture and related exercises, the student will be able to:

The JPA standard was originally part of Java EE, which is now managed by the Eclipse Foundation within Jakarta. It was released just after Java 5, which was the first version of Java to support annotations. It replaced the older, heavyweight Entity Bean Standard — that was ill-suited for the job of realistic O/R mapping — and progressed on a path that was in line with Hibernate. There are several persistence providers of the API

Access to JPA requires declaring a dependency on the JPA interface (jakarta.persistence-api) and a provider implementation (e.g., hibernate-core). This is automatically added to the project by declaring a dependency on the spring-boot-starter-data-jpa module.

The following shows a subset of the dependencies brought into the application by declaring a dependency on the JPA starter.

From these dependencies we have the ability to define and inject various JPA beans.

JPA has its own defined bootstrapping constructs that involve settings in persistence.xml and entity mappings in orm.xml configuration files. These files define the overall persistence unit and include information to connect to the database and any custom entity mapping overrides.

Spring Boot JPA automatically configures a default persistence unit and other related beans when the @EnableJpaRepositories annotation is provided. @EntityScan is used to identify packages for @Entities to include in the persistence unit.

By default, this configuration will scan packages below the class annotated with the @EntityScan annotation. We can override that default using the attributes of the @EntityScan annotation.

Spring Boot provides convenient ways to provide property-based configurations through its standard property handing, making the connection areas of persistence.xml unnecessary (but still usable). The following examples show how our definition of the DataSource for the JDBC/SQL example can be used for JPA as well.

JPA provides the capability to automatically generate schema from the Persistence Unit definitions. This can be configured to write to a file to be used to kickstart schema authoring. However, the most convenient use for schema generation is at runtime during development.

Spring Boot will automatically enable runtime schema generation for in-memory database URLs. We can also explicitly enable runtime schema generation using the following hibernate property.

The JPA provider can be configured to generate schema to a file. This can be used directly by tools like Flyway or simply to kickstart manual schema authoring.

The following configuration snippet instructs the JPA provider to generate a create and drop commands into the same drop_create.sql file based on the metadata discovered within the PersistenceContext. Hibernate has the additional features to allow for formatting and line termination specification.

action can have values of none, create, drop-and-create, and drop ^[1]

create/drop-source can have values of metadata, script, metadata-then-script, or script-then-metadata. metadata will come from the class defaults and annotations. script will come from a location referenced by create/drop-script-source

It is useful to see database SQL commands coming from the JPA/Hibernate layer during early stages of development or learning. The following properties will print the JPA SQL commands and values that were mapped to the SQL substitution variables.

The following cleaned up output shows the result of the activated debug. We can see the individual SQL commands issued to the database as well as the parameter values used in the call and extracted from the response.

Spring Boot JPA will automatically scan for @Entity classes. We can provide a specification to external packages to scan using the @EntityScan annotation.

The following shows an example of using a String package specification to a root package to scan for @Entity classes.

The following example, instead uses a Java class to express a package to scan. We are using a specific @Entity class in this case, but some may define an interface simply to help mark the package and use that instead. The advantage of using a Java class/interface is that it will work better when refactoring.

The JPA Persistence Unit represents the overall definition of a group of Entities and how we interact with the database. A defined Persistence Unit can be injected into the application using an EntityManagerFactory. From this injected class, clients can gain access to metadata and initiate a Persistence Context.

A Persistence Context is a usage instance of a Persistence Unit and is represented by an EntityManager. An @Entity with the same identity is represented by a single instance within a Persistence Context.

Injected EntityManagers reference the same Persistence Context when called within the same thread. That means that a Song loaded by one client with ID=1 will be available to sibling code when using ID=1.

By convention and supplied annotations, the class as shown above would:

Many/all of the convention defaults can be customized by further annotations. We commonly need to:

We create a new object in the database by calling persist() on the EntityManager and passing in an @Entity instance that represents something new. This will:

The following snippet shows a partial DAO implementation using JPA.

A database INSERT SQL command will be queued to the database as a result of a successful call and the @Entity instance will be in a managed state.

In the managed state, any changes to the @Entity will result in a future UPDATE SQL command. Updates are issued during the next JPA session "flush". JPA session flushes can be triggered manually or automatically prior to or no later than the next commit.

JPA supplies a means to get the full @Entity using its primary key.

If the instance is not yet loaded into the Persistence Context, SELECT SQL command(s) will be issued to the database to obtain the persisted state. The following snippet shows the SQL generated by Hibernate to fetch the state from the database to realize the @Entity instance within the JVM.

From that point forward, the state will be returned from the Persistence Context without the need to get the state from the database.

JPA provides many types of queries

The following snippet shows an example of executing a JPAQL Query.

The following shows how our JPAQL snippet mapped to the raw SQL issued to the database. Notice that our Song @Entity reference was mapped to the REPOSONGS_SONG database table.

Not every change to an @Entity and call to an EntityManager results in an immediate 1:1 call to the database. Some of these calls manipulate an in-memory cache in the JVM and may get issued in a group of other commands at some point in the future. We normally want to allow the EntityManager to cache these calls as much as possible. However, there are times (e.g., prior to making a raw SQL query) where we want to make sure the database has the current state of the cache.

The following snippet shows an example of flushing the contents of the cache after changing the state of a managed @Entity instance.

Whether is was explicitly issued or triggered internally by the JPA provider, the following snippet shows the resulting UPDATE SQL call to change the state of the database to match the Persistence Context.

JPA provides a means to delete an @Entity from the database. However, we must have the managed @Entity instance loaded in the Persistence Context first to use this capability. The reason for this is that a JPA delete can optionally involve cascading actions to remove other related entities as well.

The following snippet shows how a managed @Entity instance can be used to initiate the removal from the database.

The following snippet shows how the remove command was mapped to a SQL DELETE command.

There are two commands that will remove entities from the Persistence Context. They have their purpose, but know that they are rarely used and can be dangerous to call.

I only bring these up because you may come across class examples where I am calling flush() and clear() in the middle of a demonstration. This is purposely mimicking a fresh Persistence Context within scope of a single transaction.

Calling clear() or detach() will evict all managed entities or targeted managed @Entity from the Persistence Context — loosing any in-progress and future modifications. In the case of returning redacted @Entities — this may be exactly what you want (you don’t want the redactions to remove data from the database).

The injected EntityManager is the target of our application calls and the transaction gets associated with that object. The following snippet shows the provider throwing a TransactionRequiredException when the calling persist() on the injected EntityManager when no transaction has been activated.

Although you will find transaction methods on the EntityManager, these are only meant for individually managed instances created directly from the EntityManagerFactory. Transactions for injected an EntityManager are managed by the container and triggered by the presence of a @Transactional annotation on a called bean method within the call stack.

This next example annotates the calling @Test method with the @Transactional annotation to cause a transaction to be active for the three (3) contained EntityManager calls.

Logically speaking, the transaction handling done on behalf of @Transactional is similar to the snippet shown below. However, as complicated as that is — it does not begin to address nested calls. Also note that a thrown RuntimeException triggers a rollback and anything else triggers a commit.

We can alternatively push the demarcation of the transaction boundary down to the @Component methods.

The snippet below shows a DAO @Component that designates each of its methods being @Transactional. This has the benefit of knowing that each of the calls to EntityManager methods will have the required transaction in place — whether it is the right one is a later topic.

The following example shows the calling code invoking methods of the DAO @Component in independent transactions. The code works because there really is no dependency between the INSERT and SELECT to be part of the same transaction, as long as the INSERT commits before the SELECT transaction starts.

The following shows the SQL triggered by the snippet above with the different transactions annotated.

However, we do not always get that lucky — for individual, sequential transactions to play well together. JPA entities follow the notation of managed and unmanaged/detached state.

The following snippet shows an example of where a follow-on method fails because the EntityManager requires that @Entity be currently managed. However, the end of the create() transaction made it detached.

The following text shows the error message thrown by the EntityManager.remove call when a detached entity is passed in to be deleted.

We can get things to work better if we encapsulate methods behind a @Service method defining good transaction boundaries. Lacking a more robust application, the snippet below adds the @Transactional to the @Test method to have it shared by the three (3) DAO @Component calls — making the @Transactional annotations on the DAO meaningless.

There are several attributes that can be set on the @Transactional annotation. A few of the more common properties to set include