Java persistence api 2.1

Agenda - Overview - OR Mapping and Entity Introduction - Entity Manager - Transactions - Persistence Context - Relationships - Query Capabilities - Criteria

So, what's the big deal ? - Relational DB and Java are world apart - JDBC - Mandates manual marshaling - SQL Queries are difficult to manage - No compile time support - Boiler plate - Database portability - EJB 2.1 - Beast - Horrible to work with - Need of the hour : Lightweight POJO framework

What we need to save the day ? - Higher level abstraction above JDBC - Provide object view of RDBMS resources - Simple to configure - Lightweight - Unobtrusive - Local, but Mobile - Integration and Testability - Above all, Fun to work with

JPA - All of the items listed in prev slide and ... - Feature rich - Spec is about 500+ pages - More than one way to do, that way looks complex - Can be used in JavaEE as well as JavaSE environments - Wait, we do have alternatives - Data Mapper - Java Data Objects - JDBC

History - JPA 1.0 (2006) - Part of EJB 3.0 Spec - Start over (Leaving Legacy Entity framework) - Leading ORM experts on the panel (Hibernate, TopLink, etc) - JPA 2.0 (2009) - Added significant amount of features to catch up with ORM vendors - Criteria API - Bean Validation - Metamodel - JPA 2.1 (2013) - Converters - Criteria Update/Delete - Stored Procedures

Big Players - Client - JPA Spec API - JPA implementation - Hibernate - EclipseLink (prev TopLink) - Apache OpenJPA - Database Driver - DB - App Level : <persistence-unit> - DB location : JNDI or DB URL - List of Entity classes - JPA provider : Hibernate - Each Entity Class - Table name - Column names - Client that uses JPA API Code / Configuration

Lab - 1 - Module Setup - Step 1 : Create a git repo - Step 2 : Create a maven module (all defaults) - Step 3 : Git commit - Step 4 : Add Dependencies - Client (JUnit) - JPA Spec API - Hibernate Core - Entity Manager - Database driver jar - Step 5 : Add JPA configuration file : persistence.xml - Step 6 : Assert em.isOpen() - Step 7 : Git commit

OR Mapping - Class <-> Table - Property <-> Column - Properties without mapping to any column : Transient - Instance of Class <-> Row in the table - Relies on Convention over Configuration - Same old POJO underneath - Entities are still EJBs ? Yes and No ! - Typically created with new operator - Like SBs to container, Entities to EntityManager - Resides on server but client directly interacts with them unlike EJB siblings - Can define DB schema (not for production use)

Lab - 2 : Find Employee - Step 1 : Employees Entity - Step 2 : persistence.xml using MySQL Employees DB - Step 3 : Assert employee presence - Step 5 : Getters and Setters - Step 6 : Updated test run

Object-Relational Mapping - POJO needs something to become Entity - 2 Ways : Annotations or XML - Two types of Annotations - Logical - Describes object model - @Entity, @Basic, @Temporal etc. - Physical - Describes physical schema - @Table, @Column etc. - Configuration by Exception - Optional (Almost) - Can be specified on Fields or Bean Properties - Field annotations : Getters/Setters ignored - Bare minimum : @Entity and @Id annotations

Mapping simple types - Java Primitive types and Wrappers - Byte[], Byte[], char[], Character[] - java.lang.String - java.math.BigInteger, BigDecimal - java.util.Date, Calendar - java.sql.Date, Time, Timestamp - Enums

Entity, Who are you ? - Entity must have an identity - Annotate the field with @Id - Equivalent of primary key - Primary key not mandatory in DB table - Multiple rows with same value in @Id mapped column. Trouble! - Composite primary key - @IdClass - @EmbeddedId - @MapsId

ID Generation - 4 Types - AUTO - For prototyping only - IDENTITY - SEQUENCE - TABLE - DB agnostic - IDENTITY and SEQUENCE need DB support

Serializable Entities - Not mandated by Spec - Application can opt for when - Entities are shared across VMs - Entities are stored in (clustered/serialized) sessions

JPA Key Elements Persistence Source EntityManagerFactory Persistence Context

Persistence Unit (Tangible) - Named configuration of entity classes

EntityManager (Tangible) - Central authority - Qualifies simple POJOs into Entities - Almost entire API is built in this one interface - Provides API to - Do CRUD - Query - Synchronize with Database - Automatically sync to DB - 1st Level Caching - Works with JTA in server env

EntityManager (Tangible) - Obtained from EntityManagerFactory - Not thread-safe and must not be shared between threads - Java EE - Can be obtained directly using CDI injection or JNDI lookup - Typically a transaction involves multiple components - Need same entity context all through the transaction - Multiple entity managers (within a tx) automatically points to same Persistence Context - We don't have to pass reference of EntityManager between calls - Java SE - Using standalone bootstrap class Persistence - Each call to emf.createEntityManager() creates a new isolated persistence context

Persistence Context (Intangible) - Invisible - A set of managed Entity objects - Associated to a Persistence Unit - Managed by one or more EntityManagers - Only one Entity with same identity - Entities contained within are “managed”

Transaction - ACID - Transaction Demarcation : Act of beginning or completing - JPA supports two types - Resource Local - JavaSE and JavaEE (without container support) applications - Always application demarcated - JTA - aka Global Transactions - Spans across resources (multiple DBs, Messaging server, etc…) - Demarcated by containers (most of the times)

Transaction Contd... - Transaction Synchronization : Process by which a persistence context is registered with a transaction - Transaction Association : Act of binding a persistence context to a transaction - Transaction Propagation : Process of sharing a persistence context between multiple entity managers within a transaction

Entity Manager Types - EntityManager can be - Container Managed Transaction-scoped - Container Managed Extended - Application scoped - Scope is defined when the EntityManager is created

Container Managed Entity Manager - Mostly we are talking about Java EE environment - Injected via @PersistenceContext - No need to Open or Close it - Two flavors - Transaction Scoped - Extended

Transaction Scoped - Default - Lives as long as Transaction is alive - Once transaction finished, all objects are detached - Lazily created : When an operation on EntityManager is called - @PersistenceContext hands over a proxy - Stateless - Maintenance free

Transaction Scoped Contd... - Gets associated to the ongoing transaction seamlessly

Extended Context - Meant for @Stateful beans only - Begins with EM creation and live till its closed - Eagerly created : As soon as the txn begins - The context gets destroyed when @Remove on SFSB is called - Extended spans transactions and manages Entities between Txns - Caching of Entity is not the objective but mostly you will be doing it

Extended Context - Prevents Entities from becoming detached when txn ends - Client can use bean fields to hold state and interact with DB

Application managed Context - Mostly Java SE environments - Can be used in Java EE Environment as well - Application is responsible for context’s life cycle - Extended by nature and spans multiple transactions - Needs Explicit - Creation : EntityManagerFactory.createEntityManager() - Flushing/Closing : EntityManager.close() - Is standalone and not propagated with transaction - Can join transaction by EntityManager.joinTransaction() - Typically used in Unit Testing

Recommendations - Stateless Beans - Preferred way to manage persistence operations - Use @PersistantContext to inject EntityManager - Stateful Beans - Extended context - State can include EntityContext and its result data - Use JNDI lookup to get Stateful beans (no @Inject/@EJB) - In case of rollback, DO NOT revive the detached object

Caching - Concept is to avoid going to DB by maintaining an in-sync object in memory - Entity Manager serves as 1st level cache - Infinispan is default for WildFly - Caching hurdles - In memory objects are not transactional - Data sync with Database - Memory occupancy

Relationships in DB - Achieved via - Foreign Key - Mapping tables - Table with Foreign Key column is the owner

Relationships - No Entity is an Island! - Table with foreign key always ends up with single association - Roles - Employee “works in” a Department - Department “has” employees working in it - One Entity can participate in many relationships - Directionality - Unidirectional - BiDirectional -

Relationships Cntd... - Cardinality - One to One - One to Many - Many to One - Many to Many - Ordinality (aka Optionality)

Relationships Myths - Way to avoid business logic - You still have to deal with CascadeType - Gives flexibility - Too little for too much price - Lazy Vs Eager loading - OpenEntityManagerInViewFilter - Shields developer from database - To very little extent - Often the cause for killer bugs/defects -

Single Valued Associations - Cardinality of Target entity is 1 - ManyToOne - OneToOne - ManyToOne - Rules - @JoinColumn goes in Entity that has foreign key defined - @ManyToOne goes into the owning side i.e with foreign key - @OneToMany(mappedBy) goes into the target Entity in case of Bidirectional - OneToOne - Two Rules - @JoinColumn goes in Entity that has foreign key defined - @OneToOne(mappedBy) goes into the target Entity in case of Bidirectional -

Many To One - Always Source has has attribute of Target type - Enables navigation from Source to Target - @ManyToOne and @JoinColumn - Table with foreign key is owning side - Ownership is important because of foreign key column - @JoinColumn is specified on the owning side - Many to One mappings are always on owning side

Many To One - @JoinColumn is optional - Default join column : targetTable_targetIdColumn - @Column won’t gel with these annotations

One To One - Almost similar to Many To One - @OneToOne and @JoinColumn - Table with foreign key is the owning side - @JoinColumn has to be on the side with foreign key

One To One Bidirectional - Source Entity already has all the information - It just needs which property on source entity has it - @OneToOne(mappedBy)

Collection Valued Associations - Source entity references one or more Target entities - OneToMany - ManyToMany

One To Many - Nothing but Bidirectional ManyToOne - Always implies a ManyToOne presence - Always Bidirectional - Always on the target side i.e. Not the Source side - All configuration is in Source entity already - Just needs the Source entity property information - @OneToMany(mappedBy)

Many To Many - @JoinColumn is not sufficient - Can be achieved only by a join table - Difficult to say who is the owner - Either can be the owner - The target side will have @ManyToMany(mappedBy) - Absence of mappedBy will make them unidirectional

Many To Many Bidirectional - mappedBy on the target side - All it needs is the property configured in Source Entity

One To Many using a @TableJoin - @OneToMany is not just bidirectional @ManyToOne - Can be achieved with a @TableJoin

Lazy Relationships - Not specified, @ManyToOne and @OneToOne guaranteed to Eagerly load - Collection valued relationships by default is Lazily load - Provider may choose to do Eager loading

Queries - CRUD - Retrieval Rules - As expected, constructed using EntityManager - API - Query - TypedQuery - Type - Static - Annotation or XML - Dynamic - JPQL - Criteria - Dynamic queries are expensive

JPQL - Limited yet powerful - Metamodel is not mandatory (almost) - Limited compile time safety - Two types - @NamedQuery - Dynamic string query

Criteria API - Programmatic control - Robust - Uses Objects instead of Strings - Can result in bloated code - More than One way to do it - Query is prepared dynamically - Allows flexible filtering

Criteria Query - Entity Result

References - JPA 2.1 Specification (Not for humans) - JPA 2.1 Java Doc (Amazingly small) - (Blog) JPA 2.1 – 12 features every developer should know - MySQL Employees Sample DB

Java persistence api 2.1

More Related Content

What's hot

Viewers also liked

Similar to Java persistence api 2.1

Recently uploaded

In this document

Java persistence api 2.1