The document provides an overview of Java Persistence API (JPA) terminology and concepts. It defines key JPA terms like entity, persistence unit, entity manager, and persistence context. It describes entity characteristics and the different types of entity managers, persistence contexts, and transaction managers supported by JPA. The document also covers JPQL, query parameters, named queries, inheritance, collections, caching and more advanced JPA features.

1. JPA 2.1
JSR-338 Specification

2. Why JPA ?
 Java Persistence API (JPA), was introduced
into the platform to bridge the gap between
object-oriented domain models and relational
database systems
 API is part of javax.persistence.* package
distributed by different vendors hibernate-jpa-
2.1-api.jar

4. JPA Terminology
 Entity: It is nothing but a java representation of the database
table that should have characteristics like persist ability, identity,
transactional and granularity.
 Persistence Unit: Configuration of Entities and DB access
information. (persistence.xml file)
 EntityManagerFactory: Factory of Entity Managers which we
can create by passing Persistence Unit.
 EntityManager: Different API calls performed on entities are
managed by the single interface called EntityManager.
 PersistenceContext: Set of entities which are managed by the
entity manager are called persistence context.
 Persistence Provider: Provides underlying implementation to
the APIs. (hibernate, eclipse link etc..)

6. Characteristics of an Entity
An entity class must follow these requirements.
 The class must be annotated with the javax.persistence.Entity annotation.
 The class must have a public or protected, no-argument constructor. The
class may have other constructors.
 The class must not be declared final. No methods or persistent instance
variables must be declared final.
 If an entity instance is passed by value as a detached object, such as
through a session bean’s remote business interface, the class must
implement the Serializable interface.
 Entities may extend both entity and non-entity classes, and non-entity
classes may extend entity classes.
 Persistent instance variables must be declared private, protected, or
package-private and can be accessed directly only by the entity class’s
methods. Clients must access the entity’s state through accessor or
business methods.

7. Persistence UNIT and Context
 A persistence unit is a named configuration of entity
classes.
 A persistence context is a managed set of entity
instances.
 Every persistence context is associated with a
persistence unit, restricting the classes of the managed
instances to the set defined by the persistence unit.
 Saying that an entity instance is managed means that it
is contained within a persistence context and it can be
acted upon by an entity manager. It is for this reason
that we say that an entity manager manages a
persistence context.
 The entity manager type determines the lifetime of a
persistence context

8. Entity Manager types
 Container Managed Entity Managers: Lifecycle of the
entity manager managed by the container.
@PersistenceContext(unitName="MysqlPU")
EntityManager entityManager;
 Transaction-scoped: This means that the persistence
contexts managed by the entity manager are scoped by the
active JTA transaction, ending when the transaction is
complete.
 Extended: persistence context of an extended entity
manager will last for the entire length of the conversation of
service (ex: stateful session bean)
 Application Managed Entity Manager : application will
manages the lifecycle of the entity manager.
final EntityManagerFactory emf =
Persistence.createEntityManagerFactory("MysqlPU");
final EntityManager em = emf.createEntityManager();

9. Transaction Managers
 There are two types of transaction managers supported
by the JPA
 Resource Local : native transactions of the JDBC drivers
that are referenced by a persistence unit.
 JTA: transactions of the Java EE server, supporting multiple
participating resources, transaction lifecycle management,
and distributed XA transactions.
 Container-managed entity managers always use JTA
transactions, while application-managed entity managers
can use either type.
 Because JTA is typically not available in Java SE
applications, the provider needs to support only resource-
local transactions in that environment.
 The default and preferred transaction type for Java EE
applications is JTA. propagating persistence contexts with
JTA transactions is a major benefit to enterprise
persistence applications.

10. Container Managed VS Application Managed EntityManager
Container Managed EntityManager
@PersistenceContext
EntityManager em;
Application Managed EntityManager
@PersistenceUnit
EntityManagerFactory emf;
Ref: http://piotrnowicki.com/2012/11/types-of-
entitymanagers-application-managed-entitymanager/

11. Extended Vs Transactional Scoped
 This feature tells us if the EntityManager’s operations might span
across multiple transactions. By default the Transactional
Persistence Context is used which means that all changes are
flushed and all managed entities become detached when the
current transaction commits.
 The extended scope is available only for Stateful EJBs; it makes
perfectly sense as the SFSBs can save the state, so end of one
business method doesn’t necessary means the end of the
transaction.
 With the SLSB the story is different – we have business method
that must end when the business method finishes because in
next invocation we don’t have an idea which EJB instance we’ll
end in. One method = one transaction; only transactional-scoped
EntityManager is allowed for SLSB.
NOTE: Extended and transaction scoped PersistenceContext are
allowed only in case of container-managed EntityManagers.

12. JPQL (Java Persistence query Language)
 It is similar to SQL queries but it refers Entity
names instead of table names.
@Entity(name="Employee")
@Table(name = "employee_tbl")
public class EmployeeEntity { }
JPQL: SELECT e FROM Employee e;

13. QUERY PARAMETERS
NOTATION
 POSITIONAL PARAMETERS
final Query positionalParamQuery =
em.createQuery("SELECT e FROM Employee e WHERE
e.id>?1", EmployeeEntity.class);
positionalParamQuery.setParameter(1, 1600l);
 NAMED PARAMETERS
final Query namedParameterQuery =
em.createQuery("SELECT e FROM Employee e WHERE
e.id>=:id", EmployeeEntity.class);
namedParameterQuery.setParameter("id", 1700l);

14. Named Queries (Recommended)
Persistence providers will often take steps to
precompile JPQL named queries to SQL as part of
the deployment or initialization phase of an
application
@Entity(name = "Employee")
@Table(name = "employee_tbl")
@NamedQuery(name = "employeeById", query = "SELECT e
FROM Employee e WHERE e.id=:id")
public class EmployeeEntity {}
final Query namedQuery =
em.createNamedQuery("employeeById");
namedQuery.setParameter("id", 1801l);

15. Query Hints AND ADVANCED QUERY
Query hints are the JPA extension point for
query features. A hint is simply a string name
and object value. Hints allow features to be
added to JPA without introducing a new API.
 namedQuery.setHint("javax.persistence.query.ti
meout", 1);
 query.setHint("org.hibernate.cacheable",
Boolean.TRUE);
Advanced Query:
SELECT NEW
com.innominds.dto.Employee(e.id,e.name,e.salary,e.join
Date) FROM Employee e

16. INHERITANCE AND
POLYMORPHISM
 SELECT p FROM Project p WHERE p.employees IS
NOT EMPTY
 SELECT p FROM Project p WHERE TYPE(p) =
DesignProject OR TYPE(p) = QualityProject
 INNER JOIN QUERY EXAMPLE
SELECT pFROM Employee e JOIN e.phones p

17. SUB QUERIES
 SELECT e FROM Employee e WHERE
e.salary = (SELECT MAX(emp.salary) FROM
Employee emp)

18. COLLECTION EXPRESSION
 SELECT e FROM Employee e WHERE
e.directs IS NOT EMPTY
 SELECT m FROM Employee m WHERE
(SELECT COUNT(e) FROM Employee e
WHERE e.manager = m) > 0

19. MEMBER OF
 The MEMBER OF operator and its negated
form NOT MEMBER OF are a shorthand way
of checking whether an entity is a member of
a collection association path.
SELECT e FROM Employee e WHERE e
MEMBER OF e.directs

20. Enabling SECOND LEVEL CACHE IN 4.0 (3.3.x) or higher
 Hibernate has its own EHCache implementation from
version 4 onwards.
Add below properties to configuration
<property name="hibernate.cache.region.factory_class"
value="org.hibernate.cache.ehcache.EhCacheRegionFa
ctory"/>
<property
name="hibernate.cache.use_second_level_cache"
value="true" />
<property name="hibernate.cache.use_query_cache"
value="true" />
<property name="hibernate.generate_statistics"
value="true" />

21. Second LEVEL CACHE MODES
Second level cache can be controller using property
"javax.persistence.sharedCache.mode".
Following values are allowed
 ALL: All entity data is stored in the 2nd level cache
 NONE: No data is cached
 ENABLE_SELECTIVE: Entities marked with @Cachable
are cached
 DISABLE_SELECTIVE: All entities except
@Cachable(false) are cached
 UNSPECIFIED: Caching behavior is not specified,
Persistence provider’s default caching behavior is used.
final Properties additionalConfig = new Properties();
additionalConfig.put("javax.persistence.sharedCache.mode",
"DISABLE_SELECTIVE");

22. Cache Retrieval and Store Modes
 When the second level cache is enabled for a persistence
unit, we’re now able fine-tune the caching behavior by
setting retrieval-mode and store-mode-properties at
persistence context level or for each entity-manager
operation or query level by setting below properties.
 Retrieve Mode can be set using below property
javax.persistence.cache.retrieveMode
 Store Mode can be set using below property
javax.persistence.cache.storeMode

23. Retrieve MODES
 Following options are available for Retrieve mode
 BYPASS: The cache is bypassed and a call to the
database is used to retrieve the data.
 USE: If the data is available in the cache, it is read
from this location, else it is fetched from the database.
EX:
config.put("javax.persistence.cache.retrieveMode",
CacheRetrieveMode.USE);

24. CACHE STORE MODES
 Following options are available for store mode
 BYPASS: Don’t put anything into the cache
 REFRESH: Data is put/updated in the cache
when read and committed into the database a
refresh enforced
 USE: Data is put/updated in the cache when
read and committed into the database

25. Container Managed EntityManager
 To demonstrate this scenario I used spring
container to create EntityManagerFactory which
reads the configuration from persistence.xml file.
@Bean(name = "entityManagerFactory")
public EntityManagerFactory entityManagerFactory() {
final LocalContainerEntityManagerFactoryBean em = new
LocalContainerEntityManagerFactoryBean();
em.afterPropertiesSet();// IMP
return em.getObject();
}
NOTE: full java configuration without using persistence.xml
also possible please refer the github source code link in the
next slide.

26.  Write a Dao class and annotate
EntityManager as shown below
@Repository("personDao")
@Transactional(propagation = Propagation.REQUIRED)
public class PersonDao {
@PersistenceContext
private EntityManager entityManager;
… write your business methods here
}
NOTE: Working code available below location:
https://github.com/Innominds-jee/jpa-cm-training.git

27. Distributed Transactions using JTA
 https://www.javacodegeeks.com/2013/07/spring-
jta-multiple-resource-transactions-in-tomcat-with-
atomikos-example.html
 https://www.atomikos.com/Documentation/Hiberna
teThreeStandalone
 http://www.careerride.com/JTS-advantages-of-
JTA-over-JTS.aspx
 https://spring.io/blog/2011/08/15/configuring-
spring-and-jta-without-full-java-ee/
 http://www.javaworld.com/article/2077714/java-
web-development/xa-transactions-using-
spring.html
 http://www.byteslounge.com/tutorials/spring-
jta-multiple-resource-transactions-in-tomcat-
with-atomikos-example