Entity Persistence with JPA
•Télécharger en tant que PPT, PDF•
6 j'aime•2,449 vues
An introduction to JPA framework
![Entity Persistence with JPA [email_address]](https://image.slidesharecdn.com/jpa-100817120208-phpapp01/85/Entity-Persistence-with-JPA-1-320.jpg)
![What’s Inside ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
Similaire à Entity Persistence with JPA
Similaire à Entity Persistence with JPA (20)
Dernier
Dernier (20)
Entity Persistence with JPA
- 1. Entity Persistence with JPA [email_address]
- 11. Persistence Context Application Persistence Context Entities MyEntity A MyEntity B MyEntity C MyEntity a EntityManager MyEntity b Entity state
- 19. Thank You
Notes de l'éditeur
- Why JPA? * JPA is standardized specification and part of EJB3 specification * Many free ORM frameworks are available with can be used to develop applications of any size * Application developed in JPA is portable across many servers and persistence products (ORM frameworks). * Can be used with both JEE and JSE applications * JSE 5 features such as annotations can be used * Both annotations and xml based configuration support
- Entity Entity is the persistence (POJO) objects that represent one record in the table. The Entity is simple annotated POJO class, which is easy to develop. Here are the characteristics of an Entity: Entity can be persisted to the relational database. Entity is identified by persistence identity (the primary key of the table)
- Persistence Context To be very precise, a persistent context manages a set of entities which in turn is managed by the EntityManager. A persistent context keeps track of the state (or the changes) that an entity object may undergo. And the EntityManager takes the support of this persistence context to commit or to undo the changes. As soon as an EntityManager object is created, it is implicitly associated with a persistence context formanaging a set of entities. Persistent Context comes in two flavors, one is the transaction-scoped persistent context and the other one is extended persistent context. Transaction-Scoped Persistence Context: Imagine that a set of entities are managed by the persistence context. At this time, we say that the entities are bound to (or attached) to the persistent context. Changes may happen to these entities and these changes will occur within a transaction. Sometimes later when the transaction ends (commits or roll-back), the entities will unbind (detached) from the persistent context. As soon as the entities are detached from the persistence context, they are no longer being managed. Any changes that happen to these entities will not be persisted as they don’t have any association with the persistence context. Such kind of persistent context whose life-time is dependent on the life-time of the transaction (for a set of entities at that particular point of time) is termed as transaction-scoped persistent context. All the transaction-scoped persistence context are configured by injecting @PersistentContext to EntityManager objects , like this, @PersistenceContext(name=”PersistentUnitName”) private EntityManager entityManager; [Note: There is no such public interface called PersitenceContext in the Java Persistence API. The EntityManager may implicitly depend on a virtual Persistence Context class formanaging the entities. So, creating a transaction-scoped persistence context is nothing but creating an EntityManager object that has been configured with @PersistenceContext annotation.] Extended Persistence Context: Unlike transaction-scoped persistence context, where the life-time of the persistence context will end as soon the transaction is completed, a persistence context may be configured to live even after a transaction completes. In such a case, all the entities that are managed by such a persistence context will still be in a manageable state only even after the transaction ends. They won’t be detached from the context. Such long-lived persistence context that will continue to exist even after the completion of a transaction is called extended persistence context. All the extended persistence context objects are created and managed manually by the application code only (that is by the developers). [As soon as an EntityManager object is created, an implicit Persistence context will be associated with it and it is soon kept open and prepared formanaging a set of entities, meaning that the calling EntityManager.isOpen() method will always return true. Calling the EntityManager.clear() method will clear the current persistence context associated with the EntityManager and all the entities that have their associations will now be cleared and they become detached from the EntityManager. To release all the resources referenced by the EntityManager, call the close() method, After this method call, calling any of the methods will throw IllegalStateException.]
- EntityManager The EntityManager interface is providing the API for interacting with the Entity. Some of the functions provided by EntityManager API are: persist – this method is used to save a new entity merge – this method is used to update the sate of entity into database remove – this method is used to remove the entity instance EntityManagerFactory The EntityManagerFactory is used to create an instance of EntityManager. In your application when there is no use of EntityManagerFactory or application shuts down then it is necessary to close the instance of EntityManagerFactory . Once the EntityManagerFactory is closed, all its EntityManagers are also closed.
- The Query API http://www.javabeat.net/articles/5-introduction-to-java-persistence-apijpa-6.html
- @Entity / @Table Table defaults to the class name if not annotated We choose to explicitly specify the table for each mapped class @Id All Entities require a unique identifier @Basic is the default @Column needed only if column name != field name @Transient So any field that is unannotated in your class will be persisted (or at least attempted, Remember @Basic) For fields that don’t need persistenting – they must be marked with @Transient @Enumerated To use enum as field. e.g. @Enumerated(EnumType.STRING) @Column(name = "PRSP_STATUS_EN") ProspectStatusEnum prospectStatusEnum; @Temporal The @Temporal is used to specify the type that a JPA extension must persist for entity fields of type java.util.Date and java.util.Calendar only e.g. @Temporal(TemporalType.DATE) @Column(name = "PRSP_STATUS_DT") private Date prospectStatusDate;
- Entities and Transactions All entities have the property of transactionability and their CRUD operations will take place within a transactional context. Transactions can be broadly classified into two types based on who actually owns (or manages) the transaction. They are JTA and Resource-local transaction. In the case of a J2EE Application, the default transaction type is JTA (Java Transaction API), unless explicitly specified. A method can be simply annotated with @RequiresNew (or @Requires) in which case a new transaction will always started by the container and the transaction completes as soon as themethod ends. Whereas in a J2SE application, the transaction-type defaults to Resource-local, which means that the developer (or the application code) has to explicitly start and end a transaction. It means that the user has to explicitly start a transaction with the help of EntityManager object, and then have to commit it, if everything goes normal, else have to roll-back the transaction if some error occurs. With container-managed transactions, the transactional behavior for your EJBs is determined at deployment time. A transaction attribute determines the scope of a transaction when an EJB method is invoked. It specifies whether an EJB method executes within an existing transaction context. An EJB method can have one of the following transaction attributes: Never The method must never execute within an existing transaction context. If the client invokes such a method within a transaction context, the EJB container must throw a RemoteException (EJBException for local client). NotSupported The EJB container ensures that the method doesn't execute in a transaction context. If one exists, the container suspends the transaction for the duration of the EJB method, and resumes the transaction once the method exits. Supports The method executes with or without an existing transaction context. A new transaction isn't created before the method starts, but if one exists, it will be used, and it may influence the outcome of the transaction. Required The method requires a transaction context before it is invoked. If one doesn't exist, a new transaction is created before the method starts. Mandatory The method must never execute without a transaction context. If an existing transaction context doesn't exist, the EJB container must throw a TransactionRequiredException. RequiresNew A new transaction is created regardless of whether a client transaction context exists. The existing transaction is suspended, the new transaction is created for the duration of the method call, and the existing transaction is resumed once the method terminates.