我有一个关于 Spring Data 存储库如何处理数据源连接的问题。假设 Spring Data 存储库在方法执行时打开和关闭连接以及连接，那么通过在我的服务层中声明 @Transactional 来启动事务如何跨越多个存储库调用？
谁处理数据库连接？ @Transactional 注解还是 JPA 存储库？
【问题讨论】：
标签： jpa transactions spring-data-jpa spring-data
最终是 Spring JPA / Transaction 基础架构通过EntityManager 实例的绑定管理来管理连接。事务的范围由用户代码中的@Transactional 注释控制，但最终默认在 Spring Data JPA 的存储库实现中。如果使用OpenEntityManagerInViewFilter（在 Spring Boot 1.x 和 2.x 中默认启用），则会急切地执行连接获取。
SimpleJpaRepository 配备了 Spring 的 @Transactional 注释，以便它确保在 JPA 需要它们的情况下运行事务（例如，执行对 EntityManager.persist(…) 或 ….merge(…) 的调用）。它们的默认配置确保它们自动参与以更高抽象级别开始的事务。 IE。如果你有一个 @Transactional 本身的 Spring 组件，存储库将简单地参与已经运行的事务：
@Component
class MyService {
private final FirstRepository first;
private final SecondRepository second;
// Constructor omitted for brevity
@Transactional
void someMethod() {
… = first.save(…);
… = second.save(…);
}
}
两个存储库都参与事务，其中一个存储库出现故障将回滚整个事务。
为此，JpaTransactionManager 将使用 JPA 的 EntityManager 公开的事务管理 API 来启动事务并在 EntityManager 实例的生命周期内获取连接。详情请见JpaTransactionManager.doBegin(…)。
OpenEntityManagerInViewFilter 或 –Interceptor 的角色
除非显式停用，否则 Spring Boot 1.x 和 2.x Web 应用程序会在部署 OpenEntityManagerInViewFilter 的情况下运行。它用于创建一个EntityManager，因此很早就获得了一个连接并保持它直到请求处理的很晚，即在视图被渲染之后。这具有 JPA 延迟加载可用于视图呈现的效果，但保持连接打开的时间比仅用于实际事务工作的时间长。
该主题是一个 controversial one，因为它在开发人员便利性（遍历对象关系以在视图渲染阶段延迟加载的能力）之间进行了一个棘手的平衡，这可能会触发昂贵的额外查询并保留资源使用更长时间。
【讨论】：