【51CTO精選譯文】Java EE 5平臺引入了Java持久化API（Java Persistence API，JPA），它為Java EE和Java SE應用程序提供了一個基于POJO的持久化模塊。JPA處理關系數據與Java對象之間的映射，它使對象/關系（O/R）映射標準化，JPA已經被廣泛采用，已經成為事實上的O/R持久化企業標準。

Java EE 6帶來了JPA的最新版本 — JSR 317：Java持久化2.0，JPA 2.0帶來了許多新特性和增強，包括：

1、對象/關系映射增強；

2、Java持久化查詢語言增強；

3、一種新的基于標準的查詢API；

4、支持悲觀鎖定。

對象/關系映射增強

JPA 1.0支持集合的映射，但這些集合只能包含實體，JPA 2.0增加了集合映射的基礎數據類型，如String和Integer，以及嵌入式對象的集合。JPA中的嵌入式對象是一個不能存在于它自身的對象，而是作為父對象的一部分存在，即它的數據不是存在于它自己的表中，而是嵌入在父對象的表中。

JPA 2.0增加了兩個支持新的集合映射的注解：@ElementCollection 和 @CollectionTable。使用@ElementCollection注解指定集合的嵌入式對象，這些集合是獨立存儲在集合表中的，使用@CollectionTable注解指定集合表的詳細信息，如它包含的列。

下面是一個嵌入式類，表示了車輛的訪問服務，它存儲了訪問的日期，描述和費用，此外，車輛可以配備一或多個可選功能，每個功能是FeatureType類型的一個枚舉值。

public enum FeatureType { AC, CRUISE, PWR, BLUETOOTH, TV, ... }  
 
   @Embeddable 
   public class ServiceVisit {  
       @Temporal(DATE)  
       @Column(name="SVC_DATE")  
       Date serviceDate;  
 
       String workDesc;  
       int cost;  
   }  

枚舉值和嵌入式對象可以在一個表示車輛服務歷史的實體中使用，如：

@Entity 
   public class Vehicle {  
 
       @Id int vin;  
 
       @ElementCollection 
       @CollectionTable(name="VEH_OPTNS")  
  .    @Column(name="FEAT")  
       Set<FeatureType> optionalFeatures;  
 
       @ElementCollection 
       @CollectionTable(name="VEH_SVC")  
       @OrderBy("serviceDate")  
       List<ServiceVisit> serviceHistory;  
       ...  
   }  

#t#Vehicle實體中的第一對注解@ElementCollection 和 @CollectionTable指定FeatureType值存儲在VEH_OPTNS集合表中，第二對注解@ElementCollection 和 @CollectionTable指定ServiceVisit嵌入式對象存儲在VEH_SVC集合表中。

雖然在例子中沒有顯示，@ElementCollection注解有兩個屬性：targetClass 和 fetch。targetClass屬性指定基礎類或嵌入式類的類名，如果字段或屬性是使用泛型定義的，那這兩個屬性是可選的，上面這個例子就是這樣。Fetch屬性是可選的，它指定集合是延后檢索還是立即檢索，使用javax.persistence.FetchType常量，值分別用LAZY和EAGER，默認情況下，集合是延后匹配的。

JPA 2.0中還有其它許多關于對象/關系映射的增強，例如，JPA 2.0支持嵌套式嵌入，關系嵌入和有序列表，也增加了新的注解增強映射功能，通過@Access注解更靈活地支持特定的訪問類型，更多用于實體關系的映射選項，如對單向一對多關系的外鍵映射支持，通過@MapsId注解支持派生身份，支持孤體刪除。

#p#

Java持久化查詢語言增強

JPA 1.0定義了一個廣泛的Java持久化查詢語言（非正式簡稱為JPQL。有關JPQL查詢的缺陷，可參考51CTO之前發布的這篇文章），使用它你可以查詢實體和它們的持久化狀態。JPA 2.0對JPQL做了大量改進，如現在可以在查詢中使用case表達式。在下面的查詢中，如果雇員的評分為1，則通過乘以1.1對雇員的薪水進行了增長，如果評分為2，則乘以1.05，其它評分則乘以1.01。

UPDATE Employee e  
   SET e.salary =  
      CASE WHEN e.rating = 1 THEN e.salary * 1.1  
           WHEN e.rating = 2 THEN e.salary * 1.05  
           ELSE e.salary * 1.01  
      END 

JPA 2.0也為JPQL增加了大量新的運算符，如NULLIF和COALESCE，當數據庫使用其它非空數據解碼時，NULLIF運算符是非常有用的，使用NULLIF，你可以在查詢中將這些值轉換為空值，如果參數等于NULLIF，NULLIF會返回空值，否則返回第一個參數的值。

假設薪水數據保存在employee表中，數據類型為整數，卻掉的薪水解碼為-9999，下面的查詢返回薪水的平均值，為了正確地忽略卻掉的薪水，查詢使用NULLIF將-9999轉換為空值。

SELECT AVG(NULLIF(e.salary, -99999))  
   FROM Employee e  

COALESCE運算符接收一串參數，從列表中返回第一個非空值，相當于下面的case表達式：

CASE WHEN value1 IS NOT NULL THEN value1  
        WHEN value2 IS NOT NULL THEN value2  
        WHEN value3 IS NOT NULL THEN value3  
        ...  
        ELSE NULL 
   END 

假設employee表包括一個辦公電話號碼和家庭電話號碼列，無電話號碼的列使用空值表示。下面的查詢返回每個雇員的姓名和電話號碼，COALESCE運算符指定查詢返回辦公電話號碼，但如果為空，則返回家庭電話號碼，如果兩者都為空，則返回一個空值。

SELECT Name, COALESCE(e.work_phone, e.home_phone) phone  
   FROM Employee e  

#t#JPA 2.0向JPQL增加的其它運算符是INDEX，TYPE，KEY，VALUE和ENTRY。INDEX運算符指定查詢時的排序順序，TYPE運算符選擇一個實體的類型，將查詢限制到一或多個實體類型，KEY，VALUE和ENTRY運算符是JPA 2.0中的泛化映射功能的一部分。使用KEY運算符提取映射鍵，VALUE運算符提取映射值，ENTRY運算符選擇一個映射實體。

此外，JPA 2.0增加了選擇列表、以及集合值參數和非多態查詢中運算符的支持。

#p#

標準的API

JPA 2.0中引入的另一個重要特性是標準的API，利用這個API可以動態地構建基于對象的查詢，本質上，這個標準API等價于面向對象的JPQL，使用它，你可以使用基于對象的方法創建查詢，不再需要JPQL使用的字符串操作。

標準API是基于元模型的，元模型是一個提供了架構級關于持久化單元托管類的元數據的抽象模型， 元模型讓你構建強類型的查詢，它也允許你瀏覽持久化單元的邏輯結構。

通常，一個注解處理器使用元模型生成靜態元模型類，這些類提供持久化狀態和持久化單元托管類的關系，但你可以對靜態元模型類編碼。下面是一個實體實例：

@Entity public class Employee {  
     @Id Long Id;  
     String firstName;  
     String lastName;  
     Department dept;  
   }  

下面是對應的靜態元模型類：

import javax.persistence.meta,model.SingularAttribute;  
   import javax.persistence.meta,model.StaticMetamodel;  
 
 
   @Generated("EclipseLink JPA 2.0 Canonical Model Generation" 
   @StaticMetamodel(Employee.class)  
   public class Employee_ {  
     public static volatile SingularAttribute<Employee, Long> id;  
     public static volatile SingularAttribute<Employee, String> firstName;  
     public static volatile SingularAttribute<Employee, String> lastName;  
     public static volatile SingularAttribute<Employee, Department> dept;  
 
   }  

此外，JPA 2.0元模型API允許你動態訪問元模型，因此當你使用標準API時，既可以靜態訪問元模型類，也可以動態訪問元模型類。標準API提供了更好的靈活性，既可以使用基于對象的方法，又可以使用基于字符串的方法導航元模型，這意味著你有四種使用標準API的方法：

1、靜態使用元模型類

2、靜態使用字符串

3、動態使用元模型

4、動態使用字符串

無論你使用哪種方法，通過構造一個CriteriaQuery對象定義一個基于標準API的查詢時，使用一個工廠對象CriteriaBuilder構造CriteriaQuery，可以從EntityManager 或 EntityManagerFactory類中獲得CriteriaBuilder。下面的代碼構造一個CriteriaQuery對象：

EntityManager em = ... ;  
   CriteriaBuilder cb = em.getCriteriaBuilder();  
   CriteriaQuery<Customer> cq = cb.createQuery(Customer.class);  

注意CriteriaQuery對象是泛型類型，使用CriteriaBuilder 的createQuery方法創建一個CriteriaQuery，并為查詢結果指定類型。在這個例子中，createQuery 方法的Employee.class參數指定查詢結果類型是Employee。CriteriaQuery對象和創建它們的方法是強類型的。

接下來，為CriteriaQuery對象指定一個或多個查詢源，查詢源表示查詢基于的實體。你創建一個查詢源，然后使用AbstractQuery接口的from()方法將其添加到查詢。AbstractQuery接口是眾多接口中的一員，如CriteriaQuery，From和root，它們都定義在標準API中。CriteriaQuery接口繼承AbstractQuery接口的屬性。

from()方法的參數是實體類或EntityType實體的實例，from()方法的結果是一個Root對象，Root接口擴展From接口，它表示某個查詢的from子句中可能出現的對象。

下面的代碼增加一個查詢源到CriteriaQuery對象：

CriteriaBuilder cb = em.getCriteriaBuilder();  
   CriteriaQuery<Employee> cq = cb.createQuery(Employee.class);  
   Root<Employee> emp = cq.from(Employee.class);  

當你向CriteriaQuery對象添加一個或多個查詢源后，你訪問元模型，然后構造一個查詢表達式，你如何做取決于你是以靜態方式提交查詢還是以動態方式提交查詢，以及是使用元模型還是字符串導航元模型。下面是一個使用元模型類靜態查詢的例子：

cq.select(emp);  
   cq.where(cb.equal(emp.get(Employee_.lastName), "Smith"));  
   TypedQuery<Employee> query = em.createQuery(cq);  
   List<Employee> rows = query.getResultList();  

CriteriaQuery接口的select() 和 where()方法指定查詢結果返回的選擇項目。

注意，你使用EntityManager創建查詢時，可以在輸入中指定一個CriteriaQuery對象，它返回一個TypedQuery，它是JPA 2.0引入javax.persistence.Query接口的一個擴展，TypedQuery接口知道它返回的類型。

在元模型術語中，Employee_是對應于Employee實體類的規范化元模型類，一個規范化元模型類遵循JPA 2.0規范中描述的某些規則。例如，元模型類的名字來源于托管類，一般都是在托管類名字后面追加一個下劃線“_”。一個規范化元模型是一個包含靜態元模型類的元模型，這個靜態元模型對應于實體，映射的超類，以及持久化單元中的嵌入式類。實際上，這個查詢使用了規范化元模型。下面是一個完整的查詢：

EntityManager em = ... ;  
   CriteriaBuilder cb = em.getCriteriaBuilder();  
   CriteriaQuery<Employee> cq = cb.createQuery(Employee.class);  
   Root<Employee> emp = cq.from(Employee.class);  
   cq.select(emp);  
   cq.where(cb.equal(emp.get(Employee_.lastName), "Smith"));  
   TypedQuery<Employee> query = em.createQuery(cq);  
   List<Employee> rows = query.getResultList();  

下面是使用元模型API查詢的動態版本：

EntityManager em = ... ;  
   CriteriaBuilder cb = em.getCriteriaBuilder();  
   CriteriaQuery<Employee> cq = cb.createQuery(Employee.class);  
   Root<Employee> emp = cq.from(Employee.class);  
   EntityType<Employee> emp_ = emp.getModel();  
   cq.select(emp);  
   cq.where(cb.equal(emp.get(emp_.getSingularAttribute("lastName", String.class)),"Smith"));  
   TypedQuery<Employee> query=em.createQuery(cq);  
   List<Employee> rows=query.getResultList();  

#t#使用元模型API的標準查詢提供了與使用規范化元模型相同的類型，但它比基于規范化元模型的查詢更冗長。

Root的getModel()方法返回根對應的元模型實體，它也允許運行時訪問在Employee實體中聲明的持久化屬性。

getSingularAttribute()方法是一個元模型API方法，它返回一個持久化的單值屬性或字段，在這個例子中，它返回值為Smith 的lastName屬性。下面是使用字符串的元數據導航查詢的靜態版本：

EntityManager em = ... ;  
   CriteriaBuilder cb = em.getCriteriaBuilder();  
   CriteriaQuery<Employee> cq = cb.createQuery(Employee.class);  
   Root<Employee> emp = cq.from(Employee.class);  
   cq.select(emp);  
   cq.where(cb.equal(emp.get("lastName"), "Smith"));  
   TypedQuery query = em.createQuery(cq);  
   List <Employee>rows = query.getResultList();  

這個基于字符串的方法要相對容易使用些，但卻失去了元模型具有的類型安全。

#p#

支持悲觀鎖

鎖是處理數據庫事務并發的一種技術，當兩個或更多數據庫事務并發地訪問相同數據時，鎖可以保證同一時間只有一個事務可以修改數據。

鎖的方法通常有兩種：樂觀鎖和悲觀鎖。樂觀鎖認為多個并發事務之間很少出現沖突，也就是說不會經常出現同一時間讀取或修改相同數據，在樂觀鎖中，其目標是讓并發事務自由地同時得到處理，而不是發現或預防沖突。兩個事務在同一時刻可以訪問相同的數據，但為了預防沖突，需要對數據執行一次檢查，檢查自上次讀取數據以來發生的任何變化。

悲觀鎖認為事務會經常發生沖突，在悲觀鎖中，讀取數據的事務會鎖定數據，在前面的事務提交之前，其它事務都不能修改數據。

JPA 1.0只支持樂觀鎖，你可以使用EntityManager類的lock()方法指定鎖模式的值，可以是READ或WRITE，如：

EntityManager em = ... ;  
   em.lock (p1, READ);  

對于READ鎖模式，JPA實體管理器在事務提交前都會鎖定實體，檢查實體的版本屬性確定實體自上次被讀取以來是否有更新，如果版本屬性被更新了，實體管理器會拋出一個OptimisticLockException異常，并回滾事務。

對于WRITE鎖模式，實體管理器執行和READ鎖模式相同的樂觀鎖操作，但它也會更新實體的版本列。

JPA 2.0增加了6種新的鎖模式，其中兩個是樂觀鎖。JPA 2.0也允許悲觀鎖，并增加了3種悲觀鎖，第6種鎖模式是無鎖。

下面是新增的兩個樂觀鎖模式：

1、OPTIMISTIC：它和READ鎖模式相同，JPA 2.0仍然支持READ鎖模式，但明確指出在新應用程序中推薦使用OPTIMISTIC。

2、OPTIMISTIC_FORCE_INCREMENT：它和WRITE鎖模式相同，JPA 2.0仍然支持WRITE鎖模式，但明確指出在新應用程序中推薦使用OPTIMISTIC_FORCE_INCREMENT。

下面是新增的三個悲觀鎖模式：

1、PESSIMISTIC_READ：只要事務讀實體，實體管理器就鎖定實體，直到事務完成鎖才會解開，當你想使用重復讀語義查詢數據時使用這種鎖模式，換句話說就是，當你想確保數據在連續讀期間不被修改，這種鎖模式不會阻礙其它事務讀取數據。

2、PESSIMISTIC_WRITE：只要事務更新實體，實體管理器就會鎖定實體，這種鎖模式強制嘗試修改實體數據的事務串行化，當多個并發更新事務出現更新失敗幾率較高時使用這種鎖模式。

3、PESSIMISTIC_FORCE_INCREMENT：當事務讀實體時，實體管理器就鎖定實體，當事務結束時會增加實體的版本屬性，即使實體沒有修改。

你也可以指定新的鎖模式NONE，在這種情況下表示沒有鎖發生。

JPA 2.0也提供了多種方法為實體指定鎖模式，你可以使用EntityManager的lock() 和 find()方法指定鎖模式。此外，EntityManager.refresh()方法可以恢復實體實例的狀態。

下面的代碼顯示了使用PESSIMISTIC_WRITE鎖模式的悲觀鎖：

// read  
   Part p = em.find(Part.class, pId);  
 
   // lock and refresh before update  
   em.refresh(p, PESSIMISTIC_WRITE);  
   int pAmount = p.getAmount();  
   p.setAmount(pAmount - uCount);  

在這個例子中，它首先讀取一些數據，然后應用PESSIMISTIC_WRITE鎖，在更新數據之前調用EntityManager.refresh()方法，當事務更新實體時，PESSIMISTIC_WRITE鎖鎖定實體，其它事務就不能更新相同的實體，直到前面的事務提交。

更多JPA 2.0的新特性

除了前面描述的增強和新特性外，JPA 2.0可以使用Bean驗證自動驗證實體，這意味著你可以在實體上指定一個約束，例如，實體中字段的最大長度為15，當實體持久化，更新或移除時自動驗證字段，你可以在persistence.xml配置文件中使用<validation-mode>元素指定自動驗證生效的周期。

【51CTO.com譯稿，非經授權請勿轉載。合作站點轉載請注明原文譯者和出處為51CTO.com，且不得修改原文內容。】

原文：A More Complete Java Persistence API  作者：Ed Ort