支持悲觀鎖
鎖是處理數據庫事務並發的一種技術，當兩個或更多數據庫事務並發地訪問相同數據時，鎖可以保證同一時間只有一個事務可以修改數據。
鎖的方法通常有兩種：樂觀鎖和悲觀鎖。樂觀鎖認為多個並發事務之間很少出現沖突，也就是說不會經常出現同一時間讀取或修改相同數據，在樂觀鎖中，其目標是讓並發事務自由地同時得到處理，而不是發現或預防沖突。兩個事務在同一時刻可以訪問相同的數據，但為了預防沖突，需要對數據執行一次檢查，檢查自上次讀取數據以來發生的任何變化。
悲觀鎖認為事務會經常發生沖突，在悲觀鎖中，讀取數據的事務會鎖定數據，在前面的事務提交之前，其它事務都不能修改數據。
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
