JPA

  • LocalEntityManagerFactoryBean：用于简单部署环境，仅使用 JPA 进行数据访问，受到功能限制最大。

  • 从 JNDI 中获取 EntityManagerFactory：用于部署到 Jakarta EE 服务器中，允许从 JNDI 获取 EntityManagerFactory，使用标准的 Jakarta EE 引导。

  • LocalContainerEntityManagerFactoryBean：用于完整 JPA 功能，允许获取 EntityManagerFactory，完全控制其配置，支持与现有 JDBC 配置的链接，本地和全局事务，但对运行时环境和类加载器有要求。

Spring JPA（可在 org.springframework.orm.jpa 包下获取）以类似于与 Hibernate 集成的方式提供对 Java Persistence API 的全面支持，同时了解底层实现以提供其他功能。

Three Options for JPA Setup in a Spring Environment

Spring JPA 支持提供三种方法来设置 JPA EntityManagerFactory，应用程序使用它获取实体管理器。

Using LocalEntityManagerFactoryBean

你只能在简单的部署环境中使用此选项，例如独立应用程序和集成测试。

LocalEntityManagerFactoryBean 会创建一个适合简单部署环境的 EntityManagerFactory，在这些环境中应用程序仅使用 JPA 进行数据访问。工厂 Bean 使用 JPA PersistenceProvider 自动检测机制（根据 JPA 的 Java SE 引导），在大多数情况下，它只需要你指定持久单元名称。以下 XML 示例配置了这样的 Bean：

<beans>
	<bean id="myEmf" class="org.springframework.orm.jpa.LocalEntityManagerFactoryBean">
		<property name="persistenceUnitName" value="myPersistenceUnit"/>
	</bean>
</beans>

这种形式的 JPA 部署是最简单且受限最大的。你无法引用现有的 JDBC DataSource Bean 定义，也不支持全局事务。此外，持久类的编译（字节码转换）是特定于提供者的，通常需要在启动时指定特定的 JVM 代理。此选项仅适用于独立应用程序和测试环境，JPA 规范为此而设计。

Obtaining an EntityManagerFactory from JNDI

在部署到 Jakarta EE 服务器时可以使用此选项。查看服务器文档，了解如何将自定义 JPA 提供者部署到服务器中，允许使用与服务器默认值不同的提供者。

从 JNDI 获取 EntityManagerFactory（例如在 Jakarta EE 环境中），是一个修改 XML 配置的问题，如以下示例所示：

<beans>
	<jee:jndi-lookup id="myEmf" jndi-name="persistence/myPersistenceUnit"/>
</beans>

此操作假设标准 Jakarta EE 引导。Jakarta EE 服务器自动检测持久单元（实际上是应用程序 jar 文件中的 META-INF/persistence.xml 文件）和 Jakarta EE 部署描述符（例如 web.xml）中的 persistence-unit-ref 项，并为这些持久单元定义环境命名上下文位置。

在此场景中，整个持久单元部署，包括持久类的编译（字节码转换），都是由 Jakarta EE 服务器完成的。JDBC DataSource 通过 META-INF/persistence.xml 文件中的 JNDI 位置来定义。EntityManager 事务与服务器的 JTA 子系统集成。Spring 只使用获取的 EntityManagerFactory，通过依赖注入将其传递给应用程序对象，并管理持久单元的事务（通常通过 JtaTransactionManager）。

如果在同一个应用程序中使用多个持久单元，则从 JNDI 检索到的这些持久单元的 Bean 名称应该与应用程序用来引用它们的持久单元名称相匹配（例如，@PersistenceUnit 和 @PersistenceContext 注释）。

Using LocalContainerEntityManagerFactoryBean

你可以在基于 Spring 的应用程序环境中使用此选项来获得完整的 JPA 功能。这包括 Web 容器（例如 Tomcat）、独立应用程序以及具有复杂持久性要求的集成测试。

LocalContainerEntityManagerFactoryBean 可以完全控制 EntityManagerFactory 的配置，适用于需要细粒度自定义的环境。LocalContainerEntityManagerFactoryBean 基于 persistence.xml 文件、提供的 dataSourceLookup 策略以及指定的 loadTimeWeaver 创建一个 PersistenceUnitInfo 实例。这样，就可以与 JNDI 之外的自定义数据源配合使用并控制编译过程。以下示例展示了 LocalContainerEntityManagerFactoryBean 的典型 Bean 定义：

<beans>
	<bean id="myEmf" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
		<property name="dataSource" ref="someDataSource"/>
		<property name="loadTimeWeaver">
			<bean class="org.springframework.instrument.classloading.InstrumentationLoadTimeWeaver"/>
		</property>
	</bean>
</beans>

以下示例展示了典型的 persistence.xml 文件：

<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
	<persistence-unit name="myUnit" transaction-type="RESOURCE_LOCAL">
		<mapping-file>META-INF/orm.xml</mapping-file>
		<exclude-unlisted-classes/>
	</persistence-unit>
</persistence>

<exclude-unlisted-classes/> 快捷方式表明不会扫描带批注的实体类。显式的“true”值 (<exclude-unlisted-classes>true</exclude-unlisted-classes/>) 也表示不扫描。<exclude-unlisted-classes>false</exclude-unlisted-classes/> 的确会触发扫描。但是，我们建议如果你想要执行实体类扫描，则省略 exclude-unlisted-classes 元素。

使用 LocalContainerEntityManagerFactoryBean 是最强大的 JPA 设置选项，允许在应用程序中进行灵活的本地配置。它支持与现有 JDBC DataSource 的链接，支持本地和全局事务，等等。但是，它也对运行时环境提出要求，例如，如果持久性提供程序要求字节码转换，则需要具有编译支持的类加载器。

此选项可能与 Jakarta EE 服务器的内置 JPA 功能相冲突。在完整的 Jakarta EE 环境中，考虑从 JNDI 获取 EntityManagerFactory。或者，在 LocalContainerEntityManagerFactoryBean 定义（例如 META-INF/my-persistence.xml）上指定一个自定义 persistenceXmlLocation，并在应用程序 jar 文件中只包含带有该名称的描述符。由于 Jakarta EE 服务器只查找默认的 META-INF/persistence.xml 文件，因此它会忽略此类自定义持久单元，从而避免了与 Spring 驱动的 JPA 设置的冲突（例如，适用于 Resin 3.1）。

When is load-time weaving required?

并非所有 JPA 提供程序都需要 JVM 代理。Hibernate 就是一个不需要代理的例子。如果你的提供程序不需要代理，或者你有其他备选方案，例如通过自定义编译器或 Ant 任务在构建时应用增强，则不应使用加载时编译器。

LoadTimeWeaver 接口是 Spring 提供的类，它以特定方式插入 JPA ClassTransformer 实例，这取决于环境是 Web 容器还是应用程序服务器。通过一个 代理结合 ClassTransformers 通常效率不高。代理对整个虚拟机起作用并且检查加载的每个类，这在生产服务器环境中通常不受欢迎。

Spring 为各种环境提供多种 LoadTimeWeaver 实现，让 ClassTransformer 实例只针对每个类加载器应用，而不是每个虚拟机。

请参见 AOP 章节中的 Spring configuration 了解更多关于 LoadTimeWeaver 实现及其设置方面的信息，无论是通用设置还是针对各种平台（如 Tomcat、JBoss 和 WebSphere）的自定义设置。

如 Spring configuration 中所述，您可以使用 @EnableLoadTimeWeaving 注解或 context:load-time-weaver XML 元素配置一个上下文范围的 LoadTimeWeaver。所有 JPA LocalContainerEntityManagerFactoryBean 实例都会自动选取这样的全局 weaver。以下示例展示了设置一个加载时 weaver 的首选方式，它自动检测平台（如 Tomcat 的支持 weaving 的类加载器或 Spring 的 JVM 代理）和自动将 weaver 传播到所有支持 weaver 的 bean：

<context:load-time-weaver/>

<bean id="emf" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
	...
</bean>

但是，如有需要，您可以像以下示例所示，通过 loadTimeWeaver 属性手动指定专用的织入器：

<bean id="emf" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
	<property name="loadTimeWeaver">
		<bean class="org.springframework.instrument.classloading.ReflectiveLoadTimeWeaver"/>
	</property>
</bean>

无论如何配置 LTW，通过使用此技术，依赖于检测的 JPA 应用程序可以在目标平台（例如 Tomcat）中运行，而不需要代理。当托管应用程序依赖于不同的 JPA 实现时，这一点尤其重要，因为 JPA 转换器仅在类加载器级别上应用，因此彼此隔离。

Dealing with Multiple Persistence Units

对于依赖于多个持久性单元位置（例如存储在类路径中的各种 JAR 中）的应用程序，Spring 提供了 PersistenceUnitManager 作为中央存储库，以避免持久性单元发现过程，该过程可能是昂贵的。默认实现允许指定多个位置。这些位置将被解析，稍后通过持久性单元名称进行检索。（默认情况下，类路径被搜索 META-INF/persistence.xml 文件。）以下示例配置了多个位置：

<bean id="pum" class="org.springframework.orm.jpa.persistenceunit.DefaultPersistenceUnitManager">
	<property name="persistenceXmlLocations">
		<list>
			<value>org/springframework/orm/jpa/domain/persistence-multi.xml</value>
			<value>classpath:/my/package/**/custom-persistence.xml</value>
			<value>classpath*:META-INF/persistence.xml</value>
		</list>
	</property>
	<property name="dataSources">
		<map>
			<entry key="localDataSource" value-ref="local-db"/>
			<entry key="remoteDataSource" value-ref="remote-db"/>
		</map>
	</property>
	<!-- if no datasource is specified, use this one -->
	<property name="defaultDataSource" ref="remoteDataSource"/>
</bean>

<bean id="emf" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
	<property name="persistenceUnitManager" ref="pum"/>
	<property name="persistenceUnitName" value="myCustomUnit"/>
</bean>

默认实现允许自定义 PersistenceUnitInfo 实例（在将它们馈送到 JPA 提供程序之前），可以通过声明方式（通过其属性，影响所有托管单元）或编程方式（通过 PersistenceUnitPostProcessor，它允许持久性单元选择）。如果未指定 PersistenceUnitManager，则由 LocalContainerEntityManagerFactoryBean 创建一个并内部使用该管理器。

Background Bootstrapping

LocalContainerEntityManagerFactoryBean 支持通过 bootstrapExecutor 属性进行后台引导，如下面的示例所示：

<bean id="emf" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
	<property name="bootstrapExecutor">
		<bean class="org.springframework.core.task.SimpleAsyncTaskExecutor"/>
	</property>
</bean>

将实际的 JPA 提供程序引导转交给指定的执行器，然后与应用程序引导线程并行运行。公开的 EntityManagerFactory 代理可以注入到其他应用程序组件中，甚至可以响应 EntityManagerFactoryInfo 配置检查。但是，一旦其他组件访问了实际的 JPA 提供程序（例如调用 createEntityManager），这些调用会阻塞，直到后台引导完成。特别是，当您使用 Spring Data JPA 时，请确保也为其存储库设置延迟引导。

从 6.2 开始，在上下文刷新完成之前强制执行 JPA 初始化，等待异步引导在此之前完成。这使完全初始化的数据库基础结构的可用性变得可预测，并允许在 ContextRefreshedEvent 侦听器等中进行自定义后初始化逻辑。不建议将此类应用程序级的数据库初始化放入 @PostConstruct 方法或类似方法中；最好将其放在 Lifecycle.start 中（如果适用）或 ContextRefreshedEvent 侦听器中。

Implementing DAOs Based on JPA: EntityManagerFactory and EntityManager

尽管 EntityManagerFactory 实例是线程安全的，但 EntityManager 实例并非如此。所注入的 JPA EntityManager 的行为就像从应用程序服务器的 JNDI 环境中获取 EntityManager 一样，这是 JPA 规范所定义的。它将所有调用委托给当前的事务 EntityManager（如果有）。否则，它会退回到每个操作新建的 EntityManager，从而使其用法线程安全。

可以通过使用注入的 EntityManagerFactory 或 EntityManager 编写针对普通 JPA 的代码，而无需任何 Spring 依赖项。如果启用了 PersistenceAnnotationBeanPostProcessor，Spring 可以理解 @PersistenceUnit 和 @PersistenceContext 注释，这些注释位于字段和方法级别。下面的示例展示了一个使用 @PersistenceUnit 注释的普通 JPA DAO 实现：

  • Java

  • Kotlin

public class ProductDaoImpl implements ProductDao {

	private EntityManagerFactory emf;

	@PersistenceUnit
	public void setEntityManagerFactory(EntityManagerFactory emf) {
		this.emf = emf;
	}

	public Collection loadProductsByCategory(String category) {
		EntityManager em = this.emf.createEntityManager();
		try {
			Query query = em.createQuery("from Product as p where p.category = ?1");
			query.setParameter(1, category);
			return query.getResultList();
		}
		finally {
			if (em != null) {
				em.close();
			}
		}
	}
}
class ProductDaoImpl : ProductDao {

	private lateinit var emf: EntityManagerFactory

	@PersistenceUnit
	fun setEntityManagerFactory(emf: EntityManagerFactory) {
		this.emf = emf
	}

	fun loadProductsByCategory(category: String): Collection<*> {
		val em = this.emf.createEntityManager()
		val query = em.createQuery("from Product as p where p.category = ?1");
		query.setParameter(1, category);
		return query.resultList;
	}
}

前面的 DAO 并不依赖于 Spring，但仍然很好地适应 Spring 应用程序上下文。此外，DAO 利用注释需要注入默认 EntityManagerFactory，如下面的示例 bean 定义所示：

<beans>

	<!-- bean post-processor for JPA annotations -->
	<bean class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor"/>

	<bean id="myProductDao" class="product.ProductDaoImpl"/>

</beans>

作为显式定义 PersistenceAnnotationBeanPostProcessor 的替代方法，请考虑在应用程序上下文配置中使用 Spring context:annotation-config XML 元素。这样做会自动注册所有基于注释配置的 Spring 标准后处理器，包括 CommonAnnotationBeanPostProcessor 等。

请考虑以下示例：

<beans>

	<!-- post-processors for all standard config annotations -->
	<context:annotation-config/>

	<bean id="myProductDao" class="product.ProductDaoImpl"/>

</beans>

这种 DAO 的主要问题在于它总是通过工厂创建一个新的 EntityManager。您可以通过请求一个事务性的 EntityManager（也称为“共享 EntityManager”，因为它是一个用于实际事务性 EntityManager 的共享的、线程安全的代理）来避免这种情况，而不是注入工厂。下面的示例展示了如何执行此操作：

  • Java

  • Kotlin

public class ProductDaoImpl implements ProductDao {

	@PersistenceContext
	private EntityManager em;

	public Collection loadProductsByCategory(String category) {
		Query query = em.createQuery("from Product as p where p.category = :category");
		query.setParameter("category", category);
		return query.getResultList();
	}
}
class ProductDaoImpl : ProductDao {

	@PersistenceContext
	private lateinit var em: EntityManager

	fun loadProductsByCategory(category: String): Collection<*> {
		val query = em.createQuery("from Product as p where p.category = :category")
		query.setParameter("category", category)
		return query.resultList
	}
}

@PersistenceContext 注释有一个可选属性叫做 type，它默认值为 PersistenceContextType.TRANSACTION。您可以使用此默认值接收共享 EntityManager 代理。替代值 PersistenceContextType.EXTENDED 是一种完全不同的事务。这会导致一个所谓的扩展 EntityManager，它不是线程安全的，因此不能在并发访问的组件中使用，例如 Spring 管理的单例 bean。扩展 EntityManager 实例只应在有状态组件中使用，例如驻留在会话中的组件，其中 EntityManager 的生命周期不绑定到当前事务，而是完全取决于应用程序。

Method- and field-level Injection

您可以在类中的字段或方法上应用指示依赖项注入的注释（例如 @PersistenceUnit 和 @PersistenceContext）— 因此，表达式“方法级注入”和“字段级注入”。字段级注释简洁且易于使用，而方法级注释允许对注入的依赖项进行进一步处理。在这两种情况下，成员可见性（公共、受保护或私有）都不重要。 类级别的注释呢？ 在 Jakarta EE 平台上，它们用于依赖项声明，而不是用于资源注入。

注入的 EntityManager 是 Spring 管理的（知道正在进行的事务）。即使新的 DAO 实现使用 EntityManager 而不是 EntityManagerFactory 的方法级注入，但由于使用注释，因此无需更改 bean 定义。

此 DAO 样式的主要优点是它仅依赖于 Java 持久性 API。不需要导入任何 Spring 类。此外，由于了解 JPA 注释，因此 Spring 容器会自动应用注入项。这从非侵入性的角度来看很有吸引力，并且对 JPA 开发人员来说感觉更自然。

Implementing DAOs Based on @Autowired (typically with constructor-based injection)

@PersistenceUnit 和 @PersistenceContext 只能声明在方法和字段上。如何通过构造函数和其他 @Autowired 注入点提供 JPA 资源？

只要目标被定义为一个 bean（例如通过 LocalContainerEntityManagerFactoryBean），就可以通过构造函数和 @Autowired 字段/方法轻松地注入 EntityManagerFactory。注入点按原样与原始 EntityManagerFactory 定义的类型匹配。

但是，默认情况下，@PersistenceContext 样式的共享 EntityManager 引用不可用于常规依赖项注入。为了使其可用于 @Autowired 要求的基于类型的匹配，请考虑定义一个 SharedEntityManagerBean 作为 EntityManagerFactory 定义的伴随组件：

<bean id="emf" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
	...
</bean>

<bean id="em" class="org.springframework.orm.jpa.support.SharedEntityManagerBean">
	<property name="entityManagerFactory" ref="emf"/>
</bean>

或者，您可以基于 SharedEntityManagerCreator 定义一个 @Bean 方法：

@Bean("em")
public static EntityManager sharedEntityManager(EntityManagerFactory emf) {
	return SharedEntityManagerCreator.createSharedEntityManager(emf);
}

在存在多个持久化单元的情况下，每个 EntityManagerFactory 定义都需要有相应的 EntityManager bean 定义，最好使用与不同的 EntityManagerFactory 定义相匹配的限定符，以便通过 @Autowired @Qualifier("…​") 区分持久化单元。

Spring-driven JPA Transactions

我们强烈建议您阅读 Declarative Transaction Management，如果您还没有这样做，以便更详细地了解 Spring 的声明式事务支持。

用于 JPA 的建议策略是通过 JPA 的本机事务支持进行本地事务。Spring 的 JpaTransactionManager 提供了许多已知的本地 JDBC 事务的功能（例如特定事务的隔离级别和资源级只读优化），而无需 JTA 事务协调器和支持 XA 的资源。

Spring JPA 还允许一个已配置的 JpaTransactionManager 将 JPA 事务公开给 JDBC 访问代码，此外，该 JDBC 访问代码会访问相同的 DataSource，前提是已注册的 JpaDialect 支持检索底层的 JDBC Connection。Spring 为 EclipseLink 和 Hibernate JPA 实现提供了方言。请参见 next section 了解更多 JpaDialect 细节。

对于实际资源连接的 JTA 样式延迟检索，Spring 为目标连接池提供了相应的 DataSource 代理类：请参阅 LazyConnectionDataSourceProxy。这对于 JPA 只读事务特别有用，该事务通常可以从本地缓存中进行处理，而不是命中数据库。

Understanding JpaDialect and JpaVendorAdapter

作为一项高级功能，JpaTransactionManager 和 AbstractEntityManagerFactoryBean 的子类允许将自定义 JpaDialect 传递到 jpaDialect bean 属性中。JpaDialect 实现通常以特定于供应商的方式启用 Spring 支持的以下高级功能：

  • 应用特定的事务语义（如自定义隔离级别或事务超时）

  • 检索事务 JDBC Connection （用于向基于 JDBC 的 DAO 公开）

  • PersistenceException 至 Spring 的 DataAccessException 高级翻译

这对于特殊的的事务语义和高级的异常转换特别有价值。默认实现 (DefaultJpaDialect) 不提供任何特殊功能，如果需要前面列出的功能，则必须指定适当的方言。

作为一个最初主要用于 Spring 全功能 LocalContainerEntityManagerFactoryBean 设置的更广泛的提供程序适应设施，JpaVendorAdapter 将 JpaDialect 的能力与其他特定于提供程序的默认值结合在一起。指定 HibernateJpaVendorAdapter 或 EclipseLinkJpaVendorAdapter 是分别为 Hibernate 或 EclipseLink 自动配置一个 EntityManagerFactory 设置的最便捷方式。请注意，这些提供程序适配器主要设计用于与 Spring 驱动的交易管理配合使用（即与 JpaTransactionManager 一起使用）。

参阅 JpaDialect 和 JpaVendorAdapter javadoc 以获得更多有关其操作的详细信息以及如何在 Spring 的 JPA 支持中使用它们。

Setting up JPA with JTA Transaction Management

作为 JpaTransactionManager 的替代方法，Spring 还允许通过 JTA 进行多资源事务协调，无论是在 Jakarta EE 环境中还是在独立的事务协调器（如 Atomikos）中。除了选择 Spring 的 JtaTransactionManager 而不是 JpaTransactionManager 之外，您还需要采取一些进一步的步骤：

  • 基础 JDBC 连接池需要具备 XA 能力，并与您的事务协调器集成。在 Jakarta EE 环境中，这通常很简单，可以通过 JNDI 公开不同类型的 DataSource。有关详细信息，请参阅您的应用程序服务器文档。类似地，独立事务协调器通常带有特殊的 XA 集成 DataSource 变体。同样，请查看其文档。

  • JPA EntityManagerFactory 设置需要针对 JTA 进行配置。这是特定于提供商的，通常通过要在 LocalContainerEntityManagerFactoryBean 上作为 jpaProperties 指定的特有属性进行配置。如果使用 Hibernate，则这些属性甚至是特定于版本的。有关详细信息，请参阅您的 Hibernate 文档。

  • Spring 的 HibernateJpaVendorAdapter 强制执行某些面向 Spring 的默认值，如连接释放模式 on-close，它与 Hibernate 在 Hibernate 5.0 中自己的默认值匹配，但在 Hibernate 5.1+ 中不再匹配。对于 JTA 设置，确保将您的持久性单元事务类型声明为“JTA”。或者，将 Hibernate 5.2 的 hibernate.connection.handling_mode 属性设置为 DELAYED_ACQUISITION_AND_RELEASE_AFTER_STATEMENT 以恢复 Hibernate 自己的默认值。有关相关说明，请参见 Spurious Application Server Warnings with Hibernate。

  • 或者，考虑从您的应用程序服务器本身获取 EntityManagerFactory（即，通过 JNDI 查找而不是本地声明的 LocalContainerEntityManagerFactoryBean）。服务器提供的 EntityManagerFactory 可能需要在您的服务器配置中进行特殊定义（使得部署性较差），但这适用于服务器的 JTA 环境。

Native Hibernate Setup and Native Hibernate Transactions for JPA Interaction

与 HibernateTransactionManager 结合使用的本机 LocalSessionFactoryBean 设置允许与 @PersistenceContext 和其他 JPA 访问代码进行交互。现在，Hibernate SessionFactory 本机实现了 JPA 的 EntityManagerFactory 接口，Hibernate Session 句柄本机是 JPA EntityManager。Spring 的 JPA 支持工具会自动检测本机 Hibernate 会话。

因此，这种本机 Hibernate 设置可以在许多场景中替代标准 JPA LocalContainerEntityManagerFactoryBean 和 JpaTransactionManager 组合，允许在同一本地事务中使用 SessionFactory.getCurrentSession()（以及 HibernateTemplate）与 @PersistenceContext EntityManager 进行交互。这种设置还提供了更强的 Hibernate 集成和更高的配置灵活性，因为它不受 JPA 引导程序合约的约束。

在这种情况下，您不需要 HibernateJpaVendorAdapter 配置，因为 Spring 的本机 Hibernate 设置提供了更多功能（例如，自定义 Hibernate 集成器设置、Hibernate 5.3 bean 容器集成以及对只读事务的更强大的优化）。最后但并非最不重要的一点，您还可以通过 LocalSessionFactoryBuilder 表达本机 Hibernate 设置，与 @Bean 样式配置无缝集成（不涉及 FactoryBean）。

LocalSessionFactoryBean 和 LocalSessionFactoryBuilder 支持后台自举程序，就像 JPA LocalContainerEntityManagerFactoryBean 一样。请参见 Background Bootstrapping 了解简介。 在 LocalSessionFactoryBean 上，可以通过 bootstrapExecutor 属性获得此功能。在编程 LocalSessionFactoryBuilder 上，重载的 buildSessionFactory 方法采用引导执行器参数。