JPA 应用程序管理的持久性上下文数据源配置与 java 没有持久性 xml 文件

Question

JPA 规范定义了两种配置和使用方式：

1. 应用程序管理的持久性上下文
2. 容器管理的持久性上下文

使用应用程序管理的持久性上下文方法，应用程序代码使用EntityManagerFactory 直接创建EntityManager。使用 Container-managed Persistence Context，容器对此负责。

似乎这一切都只与控制EntityManager 实例（创建、销毁等）有关。

问题是。为什么我们在PersistenceProvider 类中有两种不同的方法？ （我的意思是使用不同的参数）

我的意思是这些：

1. public EntityManagerFactory createEntityManagerFactory(String emName, Map map)
2. public EntityManagerFactory createContainerEntityManagerFactory(PersistenceUnitInfo info, Map map)

第一个似乎是应用程序托管类型。它仅适用于persistence.xml 文件，因为它只能采用持久性单元的名称。第二个是容器管理类型。它可以采用PersistenceUnitInfo 对象。为什么我不能将 Application Managed 类型与自定义 PersistenceUnitInfo 参数一起使用？无论如何，这两种变体似乎都适用于容器。差异仅发生在控制EntityManager 实例中。当我们谈论EntityManagerFactory的配置时，这个对象总是驻留在一个容器内，因为我可以用@PersistenceUnit注解注入它。

这看起来很奇怪，因为我仍然可以使用 <jta-data-source> 标记为 Application 托管类型指定数据源。我可以使用 java setter 方法对 Container 托管类型执行相同的操作。如果我能做同样的事情，为什么我在一个变体中只能使用 XML 标记，而我可以在第二个变体中使用 java setter（java 配置）？

Answer 1

最典型的 JPA 案例

因此，此术语中的“容器”是指 Java EE / Jakarta EE 容器（也称为“应用程序服务器”）。我认为这可能看起来如此令人困惑的原因是因为大多数文档都面向典型的应用程序开发人员，但您所询问的代码通常是 JPA 提供者和容器提供者的责任。

在最典型的情况下，在 Java EE / Jakarta EE 容器中运行的应用程序不会使用这些 PersistenceProvider 方法。它可能会注入一个EntityManager（容器管理的持久性上下文）或注入一个EntityManagerFactory（应用程序管理的持久性上下文）。

PersistenceProvider#createContainerEntityManagerFactory(PersistenceUnitInfo info, Map map) 方法旨在让 JPA 提供程序允许 Java EE / Jakarta EE 容器创建一个 EMF，该 EMF 可能可用于容器管理和应用程序管理的持久性上下文。

在 Java SE 环境中，应用程序将调用 Persistence.createEntityManagerFactory(...)，它会找到一个 Provider 并调用其 PersistenceProvider#createEntityManagerFactory 方法。在这里，应用程序本身也不需要调用PersistenceProvider。

因此，如果您有一个典型的应用程序，并且您正试图找出要调用的 PersistenceProvider 方法，那么您可能走错了路，应该从一个更好的示例开始。

特殊情况

当您使用使用persistence.xml 加载持久性上下文的典型方法时，这一切都运作良好并且为您处理，如上所述。但是，如果您的应用程序想要做一些不同的和自定义的事情，那么您可能想要自己调用PersistenceProvider。例如。 this 是一篇稍微讨论该主题的文章。您最终可能会使用这种方法将您的应用程序绑定到特定的提供商。

如果有的话，我不确定规范对这种情况的确切说法。我会将其描述为具有更多“应用程序管理的持久性”的感觉，因为您肯定是在自己创建 EntityManager，但我不确定这是否是正确或有用的描述。