JPA的EntityManager何時可以通過普通JDBC提供性能優勢？

Question

我正在爲客戶端的數據庫應用程序工作。舊的應用程序代碼在訪問數據庫的方式上很不一致;在一些方法中它使用Hibernate對象，在另一些方法中直接創建JDBC連接並使用純SQL，在一些方法中它創建Hibernate連接並使用它們來獲得JDBC連接。無論如何，我們將檢修大量代碼以保持一致。我們的客戶聽說過JPA，並要求我們使用它，因爲客戶相信它會帶來性能優勢。

問題是，我對JPA的性能好處的理解是JPA的EntityManager帶來的巨大好處，因爲它允許您在數據庫調用之間持久保存內存中的對象。但是，我們正在處理的應用程序不是唯一訪問數據庫的應用程序，並且會在多個位置的多個實例中運行。此外，EntityManagers aren't thread-safe因此我們甚至無法在同一個應用程序的不同部分看到更改的數據。因此，看起來我們需要從每個方法中的EntityManagerFactory獲取新的EntityManager，並在方法完成時關閉它。因此，我們實際上不能長時間堅持內存中的對象，因爲其他應用程序需要我們更改我們需要的數據的數據。

目前的代碼非常混亂，移植到JPA會給可維護性和一致性帶來重大好處。但是，如果它不提供性能優勢，我們應該儘快讓客戶知道，這樣他們就不會失望。 JPA除了與持久性上下文有關的顯而易見的方面還有其他的方法嗎？

我檢查了StackOverflow上的其他問題，但是我發現了關於大批量變更的討論（example here）。我們的客戶希望一個應用程序所做的更改能夠儘快顯示給其他應用程序，因此我們的應用程序將進行一些小的更改，而不是偶爾進行批量更改。

謝謝。

Answer 1

與普通的JDBC相比，JPA不一定會給你帶來任何性能優勢。它可能對你的系統有很大的影響。這完全取決於你如何使用它。

聽起來你已經在使用Hibernate了。 JPA本身是一個規範，由許多供應商或提供商實施。 Hibernate就是其中之一（並且是我在工作中使用的JPA2提供程序）。

創建EntityManagerFactory可能需要一些時間。另一方面，創建一個EntityManger是快速和輕量級的。

如果您遇到性能不佳的情況，您可以嘗試分析代碼以查看性能問題的位置。

儘管如此，移動到單個訪問層對我來說聽起來不錯，它確實提高了可維護性和一致性。

Answer 2

JPA是OR/M的標準，使用ORM框架或持久性產品的原因有很多，並且有很多理由特別使用JPA。

原因ORM

• 省去了所有在Java中從SQL ResultSet中的「手」映射到 一個Java POJO大大減少映射的工作量。
• 通過域數據模型和/或關係數據模型更改減少了持久性代碼庫所需的工作量 。
• 利用大型持久性庫來避免開發解決方案以解決其他人已經解決的問題 。
• 避免低層次的JDBC和SQL代碼。
• 利用面向對象的編程和對象模型的使用。
• 提供數據庫和模式獨立性。
• 大多數ORM產品是免費且開源的。
• 許多企業公司爲ORM 產品提供支持和服務。
• 提供高端性能功能，如高速緩存和 複雜的數據庫和查詢優化。

原因JPA

• 它是一個標準和EJB3和Java EE的一部分。

• 許多免費和開源的產品與企業級支持。

• 跨應用程序服務器和持久性產品的可移植性 （避免供應商鎖定）。一個可用的功能規範。

• 支持Java EE和Java SE。

ORM可能是一些人的熱門話題，並且有很多ORM陣營。有那些認可特定標準或產品的人。有些人不相信ORM甚至是一般的對象，而更喜歡JDBC。有些人仍然認爲對象數據庫是最好的選擇。就個人而言，我會建議您使用任何您最喜歡的技術，但如果您從未使用過ORM或JPA，那麼可以嘗試一下，看看您是否喜歡它。以下列表提供了幾個關於爲什麼或爲什麼不使用JPA和ORM的討論。 （摘自維基）

下面是一些有用的linkes：JPA or JDBC, how are they different? ，Java Persistence/Why use JPA or ORM?，JPA is great but damned slow