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