Spring Boot Data JPA 中，由方法命名生成的删除操作（如 deleteAllByXxx）默认在只读事务中执行，而 @Modifying 自定义查询必须显式声明 @Transactional 才能参与当前事务；若配置不当，将导致事务隔离、回滚失效等一致性问题。
spring boot data jpa 中，由方法命名生成的删除操作（如 `deleteallbyxxx`）默认在只读事务中执行，而 `@modifying` 自定义查询必须显式声明 `@transactional` 才能参与当前事务；若配置不当，将导致事务隔离、回滚失效等一致性问题。
在 Spring Boot Data JPA 中，事务行为并非由“是否为删除操作”决定，而是由 方法来源 和 Spring Data 的默认事务策略 共同控制：
✅ Spring Data 自动生成的方法（如
deleteAllByOtherEntity_Id）：
底层由SimpleJpaRepository实现，默认以@Transactional(readOnly = true)执行（即使逻辑上是删除）。但注意：该只读事务仅用于方法自身调用上下文；当它被一个外部@Transactional方法调用时，会按事务传播规则（默认PROPAGATION_REQUIRED）加入外层事务——前提是外层事务存在且未被中断。⚠️ 自定义
@Query+@Modifying方法（如deleteAllByOtherEntityId）：@Modifying仅表示该查询会修改数据，不自动启用事务。必须显式添加@Transactional，否则 Spring 将以非事务方式执行（触发flush后直接提交），脱离当前事务边界，导致无法回滚。
正确配置示例
// Repository 接口（无需在接口方法上加 @Transactional）
public interface MyEntityRepository extends JpaRepository<myentity integer> {
// ✅ 自动生成：无需额外注解，调用时自动融入外层事务
void deleteAllByOtherEntity_Id(String requestNumber);
// ✅ 自定义修改：必须加 @Modifying，且需 @Transactional（推荐放在 service 层统一管控）
@Query("DELETE FROM MyEntity e WHERE e.otherEntity.id = :id")
@Modifying
void deleteAllByOtherEntityId(@Param("id") String requestId);
}</myentity>
// Service 类（统一事务入口，推荐方式）
@Service
@Transactional // 控制整个业务单元的事务边界
public class MyEntityService {
private final MyEntityRepository repository;
public void deleteByOtherEntityId(String requestId) {
// ✅ 两个方法均运行在同一个事务中，异常时整体回滚
repository.deleteAllByOtherEntity_Id(requestId); // 自动融入
repository.deleteAllByOtherEntityId(requestId); // 调用前已处于事务中
}
}
关键注意事项
- ❌ 避免在 Repository 方法上重复加
@Transactional：易引发嵌套事务、传播行为混淆（如REQUIRES_NEW导致子事务独立提交），破坏一致性。 - ✅
enableDefaultTransactions = false是危险配置：它会禁用 Spring Data JPA 的默认事务包装，导致所有仓库操作（包括findById）失去事务保障，必须手动补全——强烈建议保持默认true。 - ? 回滚失败常见原因：
- 抛出的是受检异常（
Exception子类但非RuntimeException），而@Transactional默认仅对RuntimeException和Error回滚； - 解决方案：显式声明
@Transactional(rollbackFor = Exception.class)； - 方法被
this.直接调用（绕过 Spring AOP 代理），导致事务注解失效——务必通过 Spring 容器注入调用。
- 抛出的是受检异常（
总结
Spring Data JPA 的事务设计是分层协同的：
✅ 自动生成方法依赖默认事务策略（readOnly=true 仅为优化，不影响写操作语义）；
✅ 自定义 @Modifying 查询需 @Transactional 显式声明，但应优先在 Service 层统一声明，而非 Repository；
✅ 事务一致性最终取决于调用链是否全程走 Spring 代理 + 外层 @Transactional 是否生效 + 异常类型是否匹配回滚规则。
遵循这一原则，即可确保删除操作与业务逻辑原子性一致，规避“部分提交、无法回滚”的数据风险。
