3. 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
4. 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
5. 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
6. 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
7. 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
9. 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)
10. 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
11. 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
13. 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
14. ID Generation
- 4 Types
- AUTO
- For prototyping only
- IDENTITY
- SEQUENCE
- TABLE
- DB agnostic
- IDENTITY and SEQUENCE need DB support
15. Serializable Entities
- Not mandated by Spec
- Application can opt for when
- Entities are shared across VMs
- Entities are stored in (clustered/serialized) sessions
19. 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
20. 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
21. 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”
23. 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)
24. 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
25. Entity Manager Types
- EntityManager can be
- Container Managed Transaction-scoped
- Container Managed Extended
- Application scoped
- Scope is defined when the EntityManager is created
26. 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
27. 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
30. 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
31. Extended Context
- Prevents Entities from becoming detached when txn ends
- Client can use bean fields to hold state and interact with DB
33. 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
34. 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
35. 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
36. Relationships in DB
- Achieved via
- Foreign Key
- Mapping tables
- Table with Foreign Key column is the owner
38. 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
-
40. 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
-
41. 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
-
42. 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
43. Many To One
- @JoinColumn is optional
- Default join column : targetTable_targetIdColumn
- @Column won’t gel with these annotations
44. 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
45. One To One Bidirectional
- Source Entity already has all the information
- It just needs which property on source entity has it
- @OneToOne(mappedBy)
47. 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)
48. 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
49. Many To Many Bidirectional
- mappedBy on the target side
- All it needs is the property configured in Source Entity
50. One To Many using a @TableJoin
- @OneToMany is not just bidirectional @ManyToOne
- Can be achieved with a @TableJoin
51. 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
52. Queries
- CRUD - Retrieval Rules
- As expected, constructed using EntityManager
- API
- Query
- TypedQuery
- Type
- Static - Annotation or XML
- Dynamic
- JPQL
- Criteria
- Dynamic queries are expensive
53. JPQL
- Limited yet powerful
- Metamodel is not mandatory (almost)
- Limited compile time safety
- Two types
- @NamedQuery
- Dynamic string query
54. 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