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

JPA是OR / M 的标准。使用ORM框架或持久性产品的原因有很多，特别是使用JPA的原因很多。

ORM的原因

• 消除Java中从SQL ResultSet到的所有'hand'映射 Java POJO大大减少了映射工作量。
• 减少持久性代码库所需的工作量 域数据模型和/或关系数据模型更改。
• 利用大型持久性库来避免开发解决方案 其他人已经解决的问题。
• 避免使用低级JDBC和SQL代码。
• 利用面向对象的编程和对象模型的使用。
• 提供数据库和架构独立性。
• 大多数ORM产品都是免费和开源的。
• 许多企业公司为ORM提供支持和服务 产品
• 提供高端性能功能，如缓存和 复杂的数据库和查询优化。

JPA的原因

• 它是EJB3和Java EE的标准和部分。

• 许多具有企业级支持的免费和开源产品。

• 跨应用程序服务器和持久性产品的可移植性 （避免供应商锁定）。可用且功能齐全的规范。

• 支持Java EE和Java SE。

对于某些人来说，ORM可能是一个热门话题，并且有许多ORM阵营。有些人认可特定的标准或产品。有些人不相信ORM甚至是一般的对象，而更喜欢JDBC。有些人仍然相信对象数据库是可行的方法。我个人建议你使用你最熟悉的技术，但如果你从未使用过ORM或JPA，也许试一试，看看你是否喜欢它。以下列表提供了有关为何或何不使用JPA和ORM的若干讨论。 （来自wikibooks）

  

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

Answer 2

JPA不一定会比纯JDBC具有任何性能优势。它可能会对您的系统产生很大的影响。这一切都取决于你如何使用它。

听起来你已经在使用Hibernate了。 JPA本身是一个规范，由许多供应商或提供商实现。 Hibernate就是其中之一（并且是我在工作时使用的JPA2提供程序）。

创建EntityManagerFactory可能需要一些时间。另一方面，创建EntityManger既快速又轻巧。

如果您遇到性能不佳的问题，可以尝试分析代码以查看性能问题所在。

移动到单个访问层对我来说听起来不错，它确实提高了可维护性和一致性。