JPA相關知識

這篇文章是摘自Patrick Linskey的一篇文章，主要是關於JPA相關內容的問答，相信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實現)。

問題：什麼是實現過程的最佳位置，例如，檢查許多用戶及其賬戶(在銀行應用程序中)以付給利息?是在數據庫的存儲過程當中實現，仍是在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()方法來實現該功能。

問題：JPA是否支持惰性加載?

回答：是的。默認狀況下，Collection和Map類型的字段是惰性檢索的，而其餘全部字段都是主動獲取的。經過在字段的持久化註解中指明「fetch」屬性，能夠基於各個字段靜態地控制該行爲。

問題：是否可能經過編程修改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規範團隊目前沒有計劃提供任什麼時候態功能。

問題：若是拋出樂觀鎖定異常，能夠了解哪些列發生衝突嗎

回答：不能夠。您能夠了解哪些實例失敗，但不是字段。給定失敗的實例，很容易從數據庫中加載新值，並進行比較。