Tag Archives: ORM

Java Persistence API

API specification that describes the management of relational data.

It is a standard API that provides functionalities to access, manage, persist data between Java Objects (POJO) and relational database in Java EE

It uses annotations or XML to map objects to database. These objects are called Entities

It allows querying and retrieval of data using JPQL (Java Persistence Query Language)

Why Java Persistence API?

Because it is strict standard, portable, simple and supports Persistence Mechanisms for:

Java Objects

Advanced OO Concepts

Transactional Integrity

Concurrency

Large Data Sets

Existing Schema

Queries

Persistence in this context covers three areas:

the API itself, defined in the javax.persistence package

the Java Persistence Query Language (JPQL)

object/relational metadata

Persistence Enitity / JPA Entity Class

Persistence Entity is a lightweight Java class whose state is typically persisted to a table in a relational database. Each row in the table corresponds to an instance of an entity. It is a POJO (Plain Old Java Object) class that is marked (annotated @Entity) as having the ability to represent objects in the database.

Requirements for Entity class

Marked with javax.persistence.Entity annotation

Must have public or protected no argument constructor

class, methods or persistent instance variables cannot be marked final

class must implement Serializable interface

EntityManager
In JPA a database connection is represented by the EntityManager interface. Therefore, in order to manipulate an database we need an EntityManager instance. Operations that modify database content also require an EntityTransaction instance.

JPA Implementation

Hibernate – Hibernate provides an open source object-relational mapping framework for Java. Versions 3.2 and later provide an implementation for the Java Persistence API

EclipseLink

OpenJPA

DataNucleus, more…

RESOURCE_LOCAL persistence contexts vs JTA persistence contexts

RESOURCE_LOCAL persistence contexts

JTA persistence context

<persistence-unit transaction-type=”RESOURCE_LOCAL“>

<persistence-unit transaction-type=”JTA“>

You are responsible for EntityManager (PersistenceContext/Cache) creating and tracking

container will do EntityManager (PersistenceContext/Cache) creating and tracking

Use EntityManagerFactory to create EntityManager (PersistenceContext)

You cannot use the EntityManagerFactory to get an EntityManager

You can only get an EntityManager supplied by the container

An EntityManagerFactory can be injected via the @PersistenceUnit annotation only (not @PersistenceContext)

An EntityManager can be injected via the @PersistenceContext annotation only (not @PersistenceUnit)

You are not allowed to use @PersistenceContext to refer to a unit of type RESOURCE_LOCAL

You are not allowed to use @PersistenceUnit to refer to a unit of type JTA

You must use the EntityTransaction API to begin/commit around every call to your EntityManger

The EntityManager given by the container is a reference to the PersistenceContext/Cache associated with a JTA Transaction.

If no JTA transaction is in progress, the EntityManager cannot be used because there is no PersistenceContext/Cache.

Everyone with an EntityManager reference to the same unit in the same transaction will automatically have a reference to the same PersistenceContext/Cache

The PersistenceContext/Cache is flushed and cleared at JTA commit time

With a RESOURCE_LOCAL unit and an EntityManagerFactory you should create and use exactly one EntityManager instance in your transaction to ensure there is only one active PersistenceContext/Cache for the given set of data active against the current transaction.

In any given transaction you want exactly one PersistenceContext/Cache for a given set of data. Using a JTA unit with an EntityManager created by the container will always guarantee that this is the case.