Java Persistence API (JPA)

Persistence is vital to enterprise applications because of the required access to relational databases. Applications that are developed for this environment must manage persistence themselves or use third-party solutions to handle database updates and retrievals with persistence.

The JPA specification defines the object-relational mapping internally, rather than relying on vendor-specific mapping implementations. JPA is based on the Java programming model that applies to Java Enterprise Edition (Java EE) environments, but JPA can function within a Java SE environment for testing application functions.

JPA represents a simplification of the persistence programming model. The JPA specification explicitly defines the object-relational mapping, rather than relying on vendor-specific mapping implementations. JPA standardizes the important task of object-relational mapping by using annotations or XML to map objects into one or more tables of a database. To further simplify the persistence programming model:

• The EntityManager API can persist, update, retrieve, or remove objects from a database.
• The EntityManager API and object-relational mapping metadata handle most of the database operations without requiring you to write JDBC or SQL code to maintain persistence.
• JPA provides a query language, extending the independent EJB querying language (also known as JPQL), that you can use to retrieve objects without writing SQL queries specific to the database that you are working with.

JPA is designed to operate both inside and outside of a Java Enterprise Edition (Java EE) container. When you run JPA inside a container, the applications can use the container to manage the persistence context. If there is no container to manage JPA, the application must handle the persistence context management itself. Applications that are designed for container-managed persistence do not require as much code implementation to handle persistence, but these applications cannot be used outside of a container. Applications that manage their own persistence can function in a container environment or a Java SE environment.

Java EE containers that support the EJB 3.x programming model must support a JPA implementation, also called a persistence provider. A JPA persistence provider uses the following elements to enable easier persistence management in an EJB 3.x environment:

Persistence unit

Defines a complete Object-Relational Model mapping Java classes (entities + supporting structures) with a relational database. The EntityManagerFactory uses this data to create a persistence context that can be accessed through the EntityManager.

EntityManagerFactory

Used to create an EntityManager for database interactions. The application server containers typically supply this function, but the EntityManagerFactory is required if you are using JPA application-managed persistence. An instance of an EntityManagerFactory represents a Persistence context.

Persistence context

Defines the set of active instances that the application is manipulating currently. You can create the persistence context manually or through injection.

EntityManager

The resource manager that maintains the active collection of entity objects that are being used by the application. The EntityManager handles the database interaction and metadata for object-relational mappings. An instance of an EntityManager represents a Persistence context. An application in a container can obtain the EntityManager through injection into the application or by looking it up in the Java component name-space. If the application manages its persistence, the EntityManager is obtained from the EntityManagerFactory.

Entity objects

A simple Java class that represents a row in a database table in its simplest form. Entities objects can be concrete classes or abstract classes. They maintain states by using properties or fields.

Java Persistence API and Local Transaction Contexts

WebSphere provides both global and local transaction contexts to managed components. Providing these contexts to managed components and having threads to service managed components, a transaction is always active whether for a global transaction context (GTC) or a local transaction context (LTC).

This processing has no effect on application-managed persistence contexts that is JPA EntityManagers acquired through EntityManagerFactories injected into an application with @PersistenceUnit. But, this processing can affect Container-Managed Persistence Contexts (CMTS), that is, JPA EntityManagers injected through @PersistenceContext. JPA API methods require that a TransactionRequiredException is thrown when called outside of the boundaries of a GTC, and this exception is still thrown as expected. However, while the LTC remains active and until a new GTC is started or the end of the component service invocation is reached, the CMTS persistence context remains active. Entities that are fetched by using either find or query by a CMTS EntityManager within the bounds of an LTC are still managed by that persistence context, instead of becoming immediately detached. As a result of this processing, which can seem like an unexpected behavior and difference in behavior with some JPA programming guides, the persistence context that is kept alive by the LTC is disposed of once the GTC starts, and entities that are managed by that persistence context become detached.