JPA：好與壞？常見問題集

問題：EJB專家團隊是如何擺脫事務描述符的?

　　回答：在會話bean和訊息驅動bean中，可以通過描述符和注釋來控制事務的行為。此外，我們將預設的事務屬性更改為“REQUIRED”，這個預設值比以前的值“SUPPORTS”更常用。因此，完全不必為業務方法配置事務行為。

　　JPA實體僅供本地使用，重點關注領域模型。因此，無法在JPA實體上配置事務性(或遠程邊界或安全性)。而是必須使用會話bean façade(或訊息驅動bean)，才可以通過EJB協議使用這些實體。通常來說，這是一件好事，配置安全性、遠端和事務的粒度應該比持久化資料的粒度粗很多。JPA著重關注持久化資料，以及與EJB的其他部分和Java EE規範整合起來照管其他企業關注點。

　　問題：推薦對主鍵使用“long”還是“Long”?如果允許使用null作為值，將會如何?

　　回答：這實際上取決於您的資料模型。如果您的資料模型允許主鍵為null，那麼使用Long，如果您的資料模型規定主鍵列不能為null，則使用long更合適。總的來說，我認為對於非複合主鍵，允許null作為合法值容易產生混淆，因此我傾向於使用long，而不是Long。

　　問題：您說EJB 2.0不支援繼承，但是可以在幾個不同位置(遠程/bean)使用繼承，只是不在本地使用而已。請解釋一下。

　　回答：根據EJB 2.1規範的附錄D3：

　　當前的EJB規範未指定組件繼承的概念。

　　另一方面，JPA規範確實規定了實體繼承的概念。我們已經處理了EJB 2.1規範中指出的各種問題和複雜性，現在允許完全的多態查詢和關聯。

　　問題：BEA計劃什麼時候支援/發布EJB3?

　　WebLogic Server 10 Technology Preview 是完全符合規範的Java EE 5應用伺服器。它包括完整的EJB3支援。WebLogic Server 10大概於三月下旬發布。

　　此外，Kodo 是完全符合規範的生產就緒JPA實現，並且已經發布。

　　問題：JPA是否支援組合主鍵?

　　回答：JPA支援自然ID和組合ID，以及資料庫指派或實現指派的數字值。

　　問題：是否存在Spring模板，像JDBC模板一樣可以在容器外部使用?

　　回答：是的，Spring 2有JPA模板。但是，Spring 2可以對任何標記著@Repository的bean執行JPA異常轉譯。因此，總的來說，對於新的應用程式，最好直接使用JPA API，而不是另一個模板層。對於使用模板和正在遷移到JPA的現有應用程式來說，使用模板方法比較合理。

　　此外，可以像在Java EE伺服器中一樣將JPA的持久化單元部署到Spring，Spring對JPA規範中指出的EntityManager注入和尋找服從容器規則。

　　問題：JPA是否支援JDK1.4?

　　回答：JPA需要Java 5或更新版本。

問題：使用範圍查詢時，它是否也會返回結果總數(例如，返回538項結果中的1-10項)?

　　回答：不，要想獲得總數，必鬚髮出另外一個查詢。通用模式是，在第一次執行搜尋時獲得總數，然後通過頁面瀏覽結果，將總數儲存到方便的位置(工作階段狀態、cookie等)：

　　if (isFirstPage()) { // this is the first time we're executing this query 
　　Query q = em.createQuery("SELECT COUNT(p) FROM Product p WHERE ..."); 
　　long count = ((Long) q.getSingleResult()).longValue(); 
　　// store count somewhere stateful 
　　} 
　　Query q = em.createQuery("SELECT p FROM Product p WHERE ..."); 
　　q.setFirstResult(page * PAGE_SIZE); // page is stored somewhere stateful 
　　q.setMaxResults(PAGE_SIZE); 

　　問題：具有JPA封裝器的Hibernate是不是一種EJB3實現?

　　回答：JPA規範是完整的EJB3規範的子集，因此JPA實現本身不是完整的EJB3實現。我不瞭解RedHat的EJB3實現的情況如何。但，Hibernate是JPA實現。

　　問題：與Hibernate相比，JPA是不是更好?

　　回答：JPA是規範，而Hibernate是實現。因此，這是不同事物的比較。可以肯定，使用標準API比使用專有API有更多優勢，但不存在真正的劣勢。

　　問題：是不是不再需要學習和使用Hibernate?

　　回答：規範團隊關於JPA 1的目標之一是制定一個可以由很多供應商實現的API，並且開發人員可以編碼來實現該API，而不是使用私人供應商特有的API。我們已成功實現這個目標，因此您只需使用供應商特有的API來獲得JPA規範沒有解決但您的應用程式中需要的功能。我的建議是儘可能地使用JPA API，但是當需要供應商公開但是規範中沒有提供的功能時，則使用供應商特有的API。

　　例如，OpenJPA提供了儲存點功能，但JPA規範沒有。因此，希望使用儲存點的OpenJPA開發人員應該對代碼的大部分內容使用JPA規範，而藉助OpenJPAEntityManager來設定和管理儲存點。

　　問題：規範是否解決了緩衝問題?

　　回答：JPA規範沒有解決二級緩衝問題(EntityManagerFactory-級)，但是提供了實現該緩衝必須遵守的一些資料鎖定和一致性規則，即使在啟用緩衝時也是如此。

　　有少量與緩衝有關的主題可能會在將來的JPA規範版本中解決，但是大多數緩衝主題不必指定規則，這樣，不同的供應商就可以輕鬆地完成不同的工作。此處增加的最重要的內容是一些基本緩衝控制API，如回收某些對象ID，或將一些經常訪問的ID固定到緩衝中。

　　問題：既然實體管理器承擔了所有繁重的工作負載，那麼會話bean還有什麼價值?

　　回答：EntityManager負責域物件模型和資料庫之間的互動，但是仍然在會話中實現安全性、事務控制、遠端、有狀態的臨時資料存放區，而操作單元編程模型無法解決以上問題。會話bean還是部署單元和公用服務邊界。因此，會話bean是定義所有業務代碼的地方。換而言之，會話bean是EJB容器關注的，而JPA實現是在會話bean中使用的。

　　當然，您還可以直接從servlet或JSP或其他任何可以使用Java 5的地方使用JPA。但是這樣的話，您就必須管理自己的事務、處理自己的叢集服務容錯移轉、管理自己的服務重部署等。

問題：相對於EJB2來說，EJB3可以處理多少個並發事務?

　　回答：從純會話bean的觀點來講，至少在WebLogic Server中，並發事務的數目沒有什麼差別。也就是，如果將您的應用程式從EJB2會話bean轉換到EJB3會話bean，但是完全沒有修改持久化機制，可能不會發現重大差別。這是因為EJB3規範對會話bean部分的大多數更改著重實現編程模型的改進。

　　從實體bean的觀點來講，我認為對於大多數應用程式，WebLogic Server的EJB 2.1和JPA支援的並發事務數目相同。您可能發現JPA對於非主鍵的查詢來說，延展性更高。一旦開始鑽研Kodo的 鎖定組 之類的功能，則對於固定的領域模型，可以從基於JPA的系統中獲得更多並發事務。

　　問題：如何為AquaLogic DSP應用JPA?

　　回答：AquaLogic DSP著重關注對資料的多重儲存訪問，並將資料作為資料服務提供，通常作為XML或SDO呈現這些資料。JPA規範著重關注與資料存放區互動的Java API。可以設想，JPA綁定到AquaLogic DSP，或SDO綁定到Kodo產品(BEA的JPA實現)。

　　問題：JPA是否支援惰性載入?

　　回答：是的。預設情況下，Collection和Map類型的欄位是惰性檢索的，而其他所有欄位都是主動擷取的。通過在欄位的持久化註解中指明“fetch”屬性，可以基於各個欄位靜態地控制該行為。

　　問題：什麼是實現過程的最佳位置，例如，檢查許多使用者及其帳戶(在銀行應用程式中)以付給利息?是在資料庫的預存程序中實現，還是在EJB中使用JPA實現，還是同時使用這兩種方式?

　　回答：根據我的經驗，這實際上取決於組織因素，而不是其他因素。一些工作室更喜歡在預存程序中進行大量編碼，而另一些則喜歡在Java中實現其商務邏輯。每種方法各有優勢和代價。

　　儘管如此，還是有一些問題可促使他們優先考慮其中的一種環境。在您的例子中，在資料庫中執行大量計算可能比將資料載入到記憶體中更快，因此使用預存程序可能比較合理。另一方面，資料庫承擔這麼多負載將對該應用程式的使用者產生負面影響，因此最好付出一定代價跨網路拉出這些資料，以便將該資料庫用作嚴格的儲存系統，而不是計算引擎。或者，如果應用程式的其餘部分主要使用JPA，則適用的話，可能希望使用JPQL的大批次更新功能來進行更新。

　　問題：如果不先將資料載入到記憶體中，是否可以執行大批次更新?

　　回答：是的，可以通過JPQL執行大批次更新和大大量刪除：

　　UPDATE Employee e SET e.salary = e.salary * 1.1 WHERE e.salary < 100000

　　問題：你們對Kodo JDO有什麼規劃?JPA是否會通過實現JDO的所有功能而將其取代?如果是的話，是否存在任何時間表?如果不是，你們會不會繼續積極地開發JDO?

　　回答：BEA仍然完全忠於JDO。從規範的觀點來看，我認為過一段時間之後，JPA將包含當前的JDO規範中越來越多的功能。但是，我不瞭解Sun對JDO和JPA之間的融合工作有什麼規劃。

問題：什麼是持久化單元?

　　回答：持久化單元是類和配置設定的集合，可以根據該集合建立EntityManagerFactory。它在 persistence.xml 檔案中作為一個條目出現。

　　問題：如何在WebLogic 9.2中測試JPA

　　回答：現在可以在WebLogic 9.2中使用OpenJPA或Kodo。該伺服器不執行會話bean持久化單元注入，但是在10.0伺服器中可以這麼作，並且在9.2中，沒有任何Kodo控制台整合。但是除了引導注入問題之外，應該能夠在WebLogic 9.2中成功地使用JPA，包括參與託管事務。

　　問題：JDBC串連對應於JPA中的什麼概念?

　　回答：JPA EntityManager大致相當於JDBC串連，而JPA EntityManagerFactory從概念上類似於JDBC資料來源。JPA EntityTransaction(僅在JTA / appserver上下文以外可用)相當於JDBC串連的事務控制API。

　　在OpenJPA中，EntityManager在其生命週期中可能使用多個不同的JDBC串連。請參閱 openjpa.ConnectionRetainMode 屬性的文檔瞭解詳細資料。

　　問題：關於fetch類型，如果預設是主動(eager)載入，則提供者可能忽略惰性(lazy)載入指令。因此，即使將欄位設定為惰性，也可能會載入不必要的資料。將來的規範會不會將其修改為必須與fecth類型一致?這會涉及到什麼問題?

　　回答：通常，OpenJPA永遠不會忽略使用者配置的FetchMode。這是提示而不是規則，因為惰性載入實際上是調優過程中一項關注事項，永遠都不應該對應用程式產生行為性的影響*。JPA規範力圖避免要求使用任何明確的效能調優策略，因為不同的網路拓撲結構、資料存放區系統和應用程式行為需要不同的調優關注。

　　例如，OpenJPA允許在運行時 動態控制 fetch配置。這意味著，它可能靜態地設定物件模型，使某些欄位進行惰性載入，然後動態地將其中一個欄位添加到當前的fetch計劃。這將導致OpenJPA違反靜態定義的惰性設定。

　　在當天結束時，如果實現對資料載入執行錯誤的操作，您應能夠非常輕鬆地評估其他實現，通過威脅轉移到另一個實現，以至少獲得所需的功能。這是讓大量供應商採用JPA規範的重大優勢之一。

　　*當然，如果您依靠惰性載入設定來防止載入某些資料，以免後來傳輸到不同的層(也就是為了資料安全性)，那麼惰性載入存在重要的行為性影響。在OpenJPA中，可以使用 fetch組 控制通過電纜發送資料圖時確切地分離哪些資料。

　　問題：在運行時更改fetch模式容不容易?

　　回答：JPA規範沒有為此提供任何工具。OpenJPA通過 fetch規劃 介面提供了對fetch特徵的詳細控制。JPQL的“JOIN FETCH”結構也可以用於限制主動fetch提示。

　　問題：使用樂觀鎖定時，@Version注釋僅支援int欄位嗎，它可以是datetime嗎?

　　回答：根據JPA的要求，@Version可以對int、long、short、Integer、Short、Long和Timestamp類型的欄位使用。(JPA規範的第9.1.17小節)。

　　問題：在JPA可以調用預存程序嗎?

　　回答：JPA規範僅要求支援SELECT SQL語句(通過EntityManager.createNativeQuery()調用，或@NamedNativeQuery註解或named-native-query XML元素)。但是，我認為大多數實現也多少支援以相同方式調用預存程序。

問題：在EJB3中，更新實體bean的單個欄位/列會導致更新該DB行中的所有欄位/列，還是僅更新該DB行中更改的列?

　　回答：該行為取決於實現。OpenJPA將只更新被修改欄位對應的列。但是，我們可能在某些位置添加update-all-columns選項。請參閱 OPENJPA-38。

　　問題：EJB3.0如何替換EJB2.0中的ejbLoad()、ejbStore()之類的回調方法?

　　回答：JPA規範提供了一些可以隨意(單個)實現的 回調方法。

　　問題：EJB3.0如何替換EJB2.0 CMP和BMP?

　　回答：EJB3 JPA規範對EJB2 CMP提供了功能完善的替換。JPA規範沒有解決bean管理的持久化，如果您希望實現自己的持久化，應該繼續使用BMP，或者最好使用會話bean façade進行自訂持久化。

　　問題：命名查詢可以位於JPA實體以外嗎?就像在會話bean或協助類中那樣?

　　回答：JPA實現僅掃描實體類(和映射超類以及嵌入類)來尋找命名查詢。我希望將來的JPA規範版本提供一種方式，用於將命名查詢限制到一個類對象中，到那個時候，就可以認為能夠在任何位置定義命名查詢。

　　可以在orm.xml檔案中定義命名查詢，然後使您的持久化單元指向該orm.xml檔案，JPA規範允許將任意數目的orm.xml檔案合并到一起。

　　問題：JPQL支援多資料庫查詢嗎?

　　回答：JPA規範並不要求實現必須只使用單個資料庫(甚至實現必須使用關聯式資料庫)。因此實現可以隨意提供對多個資料庫的訪問。但是，據我所知，當前的JPA實現都沒有這麼作，除非是通過資料庫方的工作來實現多資料庫查詢。

　　問題：在JPQL中，SELECT子句可以從多個實體中拉出資料嗎?

　　回答：是的。JPQL語言允許查詢彙總和投影。因此以下語句是有效JPQL語句：

　　select p.name, p.contactInfo.phoneNumber from Person p
　　select p.address.state, avg(p.salary) from Person p group by p.address.state

　　問題：JPA規範是否解決了緩衝問題?

　　回答：JPA規範僅解決給定EntityManager相關對象的事務工作集的行為。它稱之為“持久化上下文”。從某些方面來講，這是一個緩衝，但通常是為了保持事務一致性，而不是為了效能的原因。

　　JPA規範沒有解決效能緩衝，如OpenJPA的 資料緩衝 和 查詢快取。但是規範中的規則對這類效能緩衝暗示了某些行為約束。

　　總而言之，JPA規範主要關注的僅是API的行為方面，而由各種實現完成大多數效能有關的調優。儘管如此，所有可靠的實現都應該擁有某種資料緩衝，以作為選擇。

　　問題：WebLogic Server 9.0仍然僅支援EJB2.0，是嗎?

　　回答：正確。WebLogic Server 10.0是完全支援EJB3規範的第一款BEA產品。在WebLogic Server 9中可以通過BEA Kodo產品來使用JPA。

問題：關於JPA的推薦教程是什麼?

　　回答：Kodo文檔 中提供了許多JPA教程。

　　問題：是否存在任何方式，用於跨所有實體表配置表首碼?

　　回答：JPA規範中沒有提供這種方式，在OpenJPA中，可以通過建立擴充的 DBDictionary 並重寫getValidTableName()方法來實現該功能。

　　問題：是否可能通過編程修改ORM綁定(如重寫orm.xml中指定的一些ORM配置)?

　　回答：不是通過JPA規範實現的。OpenJPA提供了一些方法，用於以編程的方式建立映射資訊，並且該規範確實提供了一種方法，用於在建立EntityManager時，將特定於供應商的重寫內容傳遞給persistence.xml中的資料。

　　問題：我們正在構建一個大型應用程式，其中有350個對象堅持JPA規範。當我們使用Kodo 4.1持久化這些對象時，它的SELECT查詢最終將每個查詢的大多數表串連起來，這使得Kodo相當慢。TopLink Essentials實現僅串連少量的相關表。您對解決該問題有什麼建議?

　　回答：我認為這與“一對一”和“多對一”欄位類型的不同預設行為有關。我猜想，如果您明確地告知Kodo對“一對一”和“多對一”欄位類型執行惰性載入，就會很清楚。如果這不起作用，或者如果您希望獲得更多協助來分析您的具體用例，請寄送電子郵件到plinskey@bea.com。

　　問題：開發人員可以使用JPA來控製表的串連方式嗎?

　　回答：不能直接控制，並且不是通過規範實現的。但是，大多數實現可能提供了一些方式來影響如何串連。有關OpenJPA的詳細資料，請參閱關於 主動fetching 的文檔。

　　問題：在何處指定資料來源?

　　回答：資料來源通常是在persistence.xml中指定的，根據您的實現和應用伺服器的預設行為，可能需要為jta-data-source和/或non-jta-data-source設定提供值。

　　問題：JPA規範是否計劃在將來支援裡程碑或雙時態鏈(bi-temporal)?

　　回答：據我所知，JPA規範團隊目前沒有計劃提供任何時態功能。

　　問題：如果拋出樂觀鎖定異常，可以瞭解哪些列發生衝突嗎

　　回答：不可以。您可以瞭解哪些執行個體失敗，但不是欄位。給定失敗的執行個體，很容易從資料庫中載入新值，並進行比較。