Java Persistence API (JPA) architecture

Data persistence is the ability to maintain data between application executions. 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 Java™ Persistence API (JPA) provides a mechanism for managing persistence and object-relational mapping and functions for the EJB specifications.

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 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 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 allow for easier persistence management in an EJB 3.x environment:
Persistence unit
Consists of the declarative metadata that describes the relationship of entity class objects to 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. The persistence context can be created 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.
Attention: Injection of the EntityManager is only supported for the following artifacts:
  • EJB 3.x session beans
  • EJB 3.x message-driven beans
  • Servlets, Servlet Filters, and Listeners
  • JSP tag handlers which implement interfaces javax.servlet. jsp.tagext.Tag and javax.servlet.jsp.tagext.SimpleTag
  • JavaServer Faces (JSF) managed beans
  • the main class of the application client.
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. A transaction is always active whether it is a global transaction context (GTC) or a local transaction context (LTC) with threads that service a managed component. While this active transaction has no effect on application managed persistence contexts (that is, JPA EntityManagers acquired through EntityManagerFactories injected into an application via @PersistenceUnit), it does influence container managed persistence contexts (that is, JPA EntityManagers injected through @PersistenceContext).

JPA API methods throw a TransactionRequiredException when called outside of the boundaries of a GTC and still throws the exception as expected. However, while the LTC remains active (until a new GTC is started or the end of the component service invocation is reached) the container-managed transactions (CMT) persistence context also remains active. Remaining active means that entities fetched (by find or query) by a CMT EntityManager within the bounds of an LTC are still managed by that persistence context, instead of becoming immediately detached. This behavior can surprise some as an unexpected difference in behavior compared to some JPA programming guides. However, once a GTC begins, the persistence context kept alive by the LTC is disposed of and entities that are managed by that persistence context then become detached.