JPA and CDI JPA and EJB

Transcription

1 JPA and CDI JPA and EJB

2 Concepts: Connection Pool, Data Source, Persistence Unit Connection pool DB connection store: making a new connection is expensive, therefor some number of connections are being created during the startup of a system and stored within a pool connection pool specifies: DBMS host/port, DB name, minimum/maximum number of connections, etc. Data Source is a pair: {name, connectionpool thus connection pool can be retrieved by its name Persistence Unit specifies data source and optional list of database tables is defined in persistence.xml file COP - JPA integration 2

3 persistence.xml example <?xml version="1.0" encoding="utf-8"?> <persistence version="2.1"...> <persistence-unit name="studentspu" transaction-type="jta"> <jta-data-source>java:global/studentsdatasource</jta-data-source> </persistence-unit> <persistence-unit name="manualpu" transaction-type="resource_local"> <non-jta-data-source>java:global/studentsdatasource2 </non-jta-data-source> </persistence-unit> </persistence> COP - JPA integration 3

4 Concepts: Persistence Context and EntityManager Persistence Context cache of Entity objects Each EntityManager instance has its own single nonshared Persistence Context: one-to-one relationship Official definition (JPA 2.1 specification chapter 7.1): A persistence context is a set of managed entity instances in which for any persistent entity identity there is a unique entity instance. Within the persistence context, the entity instances and their lifecycle are managed by the entity manager. EntityManager API to work with Persistence Context to manage the cache programmatically COP - JPA integration 4

5 Entity s life-cycle (managed via EntityManager API) While entity is in this state, changes are synchronized with DB automatically!!! Persistence Context (cache) contains only managed entities!!! COP - JPA integration 5

6 Entity s life-cycle: states new The entity instance was created in memory, but not yet in the database Changes to the entity are not synchronized with the database entity is not yet managed managed The entity has a persistent identity in the database and is synchronized with the database Changes to the entity will be synchronized with the database automatically detached The entity does have a persistent identity but is not synchronized with the database removed The entity is deleted from the database COP - JPA integration 6

7 Automatic Entity synchronization with DB While an entity is in managed state its persistent fields are automatically synchronized with database Most often synchronization happens just before transaction commit Changes in database (performed by some other application) are not brought back to entity database is not being monitored for changes Sometimes we want the synchronization to happen in the middle of the transaction for example: we made some changes and we want these changes to be visible in the query that is executed later in this transaction flush() forces to performe the synchronization at once COP - JPA integration 7

8 Manual Entity refresh/save refresh(entity) data from database are overwritten over entity s data (at the end of transaction) entity2 = merge(entity1): if entity1 is managed data of entity1 is written to DB (at the end of transaction) entity1 is returned as result if entity1 is not managed (is detached) entity1 is cloned the clone is made managed (entity1 remains detached!) clone s data is written to DB (at the end of transaction) clone is returned as the result of merge() operation COP - JPA integration 8

9 Entity Life-cycle: summary While entity is in managed state its data is automatically synchronized with database least worries for a programmer Managed state may be lost in two ways: by asking to delete the entity from database by calling method remove() when Persistence Context (cache) is destroyed (in the picture: "Persistence context ends") This can be done manually by calling: EntityManager.close() COP - JPA integration 9

10 Manual EntityManager creation EntityManagerFactory emf = Persistence.createEntityManagerFactory("StudentsPU"); // rankinis sukūrimas EntityManager em = emf.createentitymanager(); try { // rankinės transakcijos: em.gettransaction().begin(); em.persist( new Student("Jonas Jonaitis") ); em.gettransaction().commit(); finally { // rankinis uždarymas em.close(); COP - JPA integration 10

11 Problems for Programmer EntityManagers must not only be created but also closed too Otherwise free memory will end soon, since entities loaded by EntityManager are being cached EntityManager is not thread-safe Different threads must use different EntityManagers It is the responsibility of the application to insure that an instance is managed by only a single EntityManager So, one global EntityManager per whole system is not a solution! COP - JPA integration 11

12 Unmanaged and Managed Persistence Contexts JPA comes with only unmanaged Persistence Contexts, programmers must: create and close EntityManager instances manage memory manage threads COP technologies (CDI, EJB, Spring) are capable to: Create EntityManager instances automatically Close EntityManager instances automatically Thus free memory Manage threads COP - JPA integration 12

13 Transactions (TX), EntityManager (EM), CDI, EJB TX: Manual (RESOURCE_ LOCAL) TX: Declarative (JTA) EM: Manual EM: Managed by CDI Managed by Spring, EJB emf.createentitymanager() em.gettransaction().begin()/.commit() emf.createentitymanager( File persistence.xml: <persistence <persistence-unit name="studentspu" transaction-type="jta"> <jta-data-source>studentsdatasource</jta-data-source> </persistence-unit> <persistence-unit name="manualpu" transaction-type="resource_local"> <non-jta-data-source>studentsdatasource2</non-jta-data-source> </persistence-unit> </persistence> COP - JPA integration 13

14 CDI ir JPA integracija (deklaratyvios EntityManager em; Life-cycle: Sukūrimas Sunaikinimas Scope: COP - JPA integration 14

15 Life-cycle public class Resources private private EntityManager createjtaentitymanager() { /* * From JavaDoc: Create a new JTA application-managed EntityManager... */ return emf.createentitymanager(synchronizationtype.synchronized); private void closeunsynchronizedentitymanager(@disposes EntityManager em) { em.close(); COP - JPA integration 15

16 @Model // tas pats public class RequestUseCaseController private Course course = new private Student student = new Student(); Use Case private CourseDAO private StudentDAO public void createcoursestudent() { student.getcourselist().add(course); course.getstudentlist().add(student); coursedao.create(course); studentdao.create(student); public List<Student> getallstudents() { return studentdao.getallstudents(); COP - JPA integration 16

17 Data Access Object public class StudentDAO private EntityManager em; public void create(student student) { em.persist(student); public List<Student> getallstudents() { return em.createnamedquery("student.findall", Student.class).getResultList(); COP - JPA integration 17

18 HTTP Request flow Presentation (UI) Business Logic Data Access DAO1 HTML template Use-case controller DAO2 DAO1 HTML template Use-case controller DAO2 COP - JPA integration 18

19 Papildoma medžiaga: EJB ir JPA Life-cycle: Transactional Extended Synchronization: Synchronized Unsynchronized COP - JPA integration 19

20 Managed Persistence Context Types Persistence Context (PC) Type is cache life-cycle specification Specifies when the cache (Persistence Context) is created and when is closed JPA specification defines two PC types: transactional PC life-cycle is scoped by a single type=persistencecontexttype.transaction) extended PC life-cycle is scoped by the life-cycle of a CDI bean type=persistencecontexttype.extended) if type is not specified, type is transactional by default COP - JPA integration 20

21 @Stateless public class Bank private EntityManager em; Example 1 public Account createaccount(string ownername) { Account account = new Account(); account.ownername = ownername; em.persist(account); return account; public Account readaccount(int acckey) { Account account = em.find(account.class, acckey); return account; public Account updateaccount(account account) { account = em.merge(account); return account; public void deleteaccount(account account) { em.remove(em.merge(account)); EJB - JPA integration 21

22 Example 1 EJB - JPA integration 22

23 @Stateless public class Bean { // this is transactional private EntityManager em; Notes for example 1 public void method1() { 1. Transaction begins 2. EntityManager is created as soon as one of its methods is called (but not sooner) 2. EntityManager is used to work with entities Leaving the method, the transaction ends. Just before transaction commit, all the changes are sent to database and EntityManager is closed. All its entities become detached. Changes, made to entities between calls to the methods above, are not synchronized with database (entities are detached!) If we want to save changes to database, we have to call EntityManager.merge() method. EJB - JPA integration 23

24 @Stateful public class Bank private EntityManager manager; Example 2 public Account createaccount(string ownername) { Account account = new Account(); account.ownername = ownername; manager.persist(account); return account; public Account readaccount(int acckey) { Account account = manager.find(account.class, acckey); return account; public void update() { // automatic managed entity synchronization is performed // just before transaction commit. public void deleteaccount(account account) { manager.remove(account); EJB - JPA integration 24

25 Example 2 EJB - JPA integration 25

26 @Stateful public class Bank { Notes for example private EntityManager manager; // EntityManager is created when session bean is created, // and is closed when session bean is destroyed public void method1() { 1. Transaction begins 2. EntityManager is used to work with entities Leaving the method, the transaction ends. Just before transaction commit, all the changes are sent to database, EntityManager remains alive. All entities remain managed. public void method2() { The same // changes, made to entities in between calls to method1 and method2, are written to database at the end of transaction! EJB - JPA integration 26

27 Persistence Context Type Comparison Transactional PC consumes less memory cache is always destroyed at the end of transaction (i.e. request) Extended PC allows web tier to navigate entity relationships cache is alive, EntityManager "sees" all the operations performed with an entity, loads related entities transparently on demand COP - JPA integration 27

28 Practical problem component decomposition If business logic is complex, we want to split it to several components client calls the first component that calls another one and so on Imagine, that all components need to work with database, so all of them EntityManager em; there will be problems if all em fields contain different EntityManagers Example: the first component loads list of entities, passes it to the second component, the second one tries to delete those entities from DB remove() method called in the second component would throw exception because entities loaded by the first EntityManager are not in the second EntityManager's cache (Persistence Context) COP - JPA integration 28

29 Possible solutions The first component in a use case (use case controller) passes its EntityManager to all other components as a parameter every method must have additional parameter of type EntityManager cumbersome JPA specification introduced EntityManager lending mechanism: persistence context propagation COP - JPA integration 29

30 1. Persistence context propagation (JPA spec. section ) If a component is called and there is no transaction or the transaction is not propagated, the persistence context is not propagated. Otherwise, the persistence context is propagated across the entity manager instances as the transaction is propagated. Most of the time COP - JPA integration 30

31 Persistence Context Propagation Client R Comp1 R Required RN RequiresNew Transaction and Persistence Context R Comp2 RN Comp5 R RN R Comp3 Comp4 Comp6 COP - JPA integration 31

32 Generalization of rules 1 and 2 Let k1 and k2 be component instances, k1 injects k2 (with the help If both components have Transactional Transactional Transactional Extended Extended Transactional Extended new Extended Extended old Extended, propagates, error, propagates, inherits, error k2 was born before k1 and already has its own EntityManager object COP - JPA integration 32

33 Generalization of rules 1 and 2 Important: if transaction does not propagate, persistence context does not propagate too Transaction will never propagate to component using RequiredNew transactional attribute This is actually OK: different transactions must work with different entity caches COP - JPA integration 33

34 Java EE 7 (JPA 2.1): Persistence Context Synchronization Type By default, a container-managed persistence context is of type SynchronizationType.SYNCHRONIZED. Such a persistence context is automatically joined to the current JTA transaction. A persistence context of type UNSYNCHRONIZED is not enlisted in any JTA transaction unless explicitly joined to that transaction by the invocation of the EntityManager jointransaction() method. When a JTA transaction exists, a persistence context of type UNSYNCHRONIZED is propagated with that transaction according to the rules in section regardless of whether the persistence context has been joined to that transaction. COP - JPA integration 34

35 Java EE 7: Synchronized and Unsynchronized PC Let k1 and k2 be component instances, k1 injects k2 (with the help If both components have Unsynchronized Unsynchronized Synchronized Synchronized Synchronized Unsynchronized Unsynchronized Synchronized, propagates, propagates, propagates, error COP - JPA integration 35

36 Summary CDI, Spring, EJB and JPA are well integrated automatic transactions, automatic cache life-cycle management, persistence context (cache) propagation Without CDI/Spring things would be much more difficult: manual transactions manual EntityManager creation and closing EntityManagers would have to be passed as parameters to other components implementing the same use-case manual thread management: programmer would have to ensure that two threads are not using the same EntityManager COP - JPA integration 36