Java Persistence/Runtime

Once you have mapped your object model the second step in persistence development is to access and process your objects from your application, this is referred to as the runtime usage of persistence. Various persistence specifications have had various runtime models. The most common model is to have a runtime API; a runtime API typically will define API for connecting to a data-source, querying and transactions.

=Entity Manager= JPA provides a runtime API defined by the  package. The main runtime class is the  class. The EntityManager provides API for creating queries, accessing transactions, and finding, persisting, merging and deleting objects. The JPA API can be used in any Java environment including JSE and JEE.

An EntityManager can be created through an, or can be injected into an instance variable in an EJB SessionBean, or can be looked up in JNDI in a JEE server.

JPA is used differently in Java Standard Edition (JSE) versus Java Enterprise Edition (JEE).

Java Standard Edition
In Java SE an  is accessed from the JPA  class through the   API. The persistent unit name is passed to the, this is the name given in the persistence unit's   file. All Java SE JPA applications must define a  file. The file defines the persistence unit including the name, classes, orm files, datasource, vendor specific properties.

JPA 1.0 does not define a standard way of specifying how to connect to the database in Java SE. Each JPA provider defines their own persistence properties for setting the JDBC driver manager class, URL, user and password. JPA has a standard way of setting the  JNDI name, but this is mainly used in JEE.

JPA 2.0 does define standard persistence unit properties for connecting to JDBC in Java SE. These include,,  ,  ,.

The JPA application is typically required to be packaged into a persistence unit jar file. This is a normal jar, that has the  file in the   directory. Typically a JPA provider will require something special be done in Java SE to enable certain features such as lazy fetching, such as static weaving (byte-code processing) of the jar, or using a Java agent JVM option.

In Java SE the  must be closed when your application is done with it. The life-cycle of the  is typically per client, or per request. The  can be shared among multiple threads or users, but the   should not be shared.

Java Enterprise Edition
In Java EE the  or   can either be looked up in JNDI, or injected into a. To look up the  in JNDI it must be published in JNDI such as through a   in a  's   file. To inject an  or   the annotation   or   are used.

In Java EE an  can either be managed (container-managed) or non-managed (application-managed). A managed  has a different life-cycle than an   managed by the application. A managed  should never be closed, and integrates with JTA transactions so local transaction cannot be used. Across each JTA transaction boundary all of the entities read or persisted through a managed  become detached. Outside of a JTA transaction a managed 's behavior is sometimes odd, so typically should be used inside a JTA transaction.

A non-managed  is one that is created by the application through a   or directly from. A non-managed  must be closed, and typically does not integrate with JTA, but this is possible through the   API. The entities in a non-managed  do not become detached after a transaction completes, and can continue to be used in subsequent transactions.

Example of lookup an EJBContext in an Entity
(Useful for Audit)

Stateful SessionBeans
/Runtime