Spring Data JPA与R2DBC Repository的saveAll方法处理同ID实体的行为差异及相关文档咨询

我来帮你梳理这两种Repository的行为差异、背后原因，以及对应的文档说明：

一、两种Repository的saveAll行为表现 #

1. Spring Data JPA的表现 #

当你调用JPA Repository的saveAll传入同ID、同版本的实体列表时，操作会成功完成，最终数据库中只会保留最后一个实体的状态，版本号自增一次。

比如你给出的代码：

public interface JpaRepository extends JpaRepository<Entity, String> {}

// 手动构建两个同ID、同版本的实体
Entity entity1 = Entity.build()
    .version(1L)
    .id(123)
    .status("NEW")
    .build();

Entity entity2 = Entity.build()
    .version(1L)
    .id(123)
    .status("IN_PROGRESS")
    .build();

// 执行saveAll
jpaRepository.saveAll(List.of(entity1, entity2));

最终数据库中会得到version=2L、status="IN_PROGRESS"的记录，没有任何异常抛出。

2. Spring Data R2DBC的表现 #

换成R2DBC的Reactive Repository时，同样的操作会直接抛出乐观锁异常：

public interface R2dbcRepository extends ReactiveCrudRepository<Entity, String> {}

// 执行saveAll
r2dbcRepository.saveAll(List.of(entity1, entity2)).blockLast();

抛出的异常信息如下：

Failed to update table [entity]; Version does not match for row with
Id [123] org.springframework.dao.OptimisticLockingFailureException:
Failed to update table [entity]; Version does not match for row with
Id [123] at
org.springframework.data.r2dbc.core.R2dbcEntityTemplate.lambda$doUpdate$12(R2dbcEntityTemplate.java:637)

二、行为差异的核心原因 #

两者的本质区别在于saveAll方法的底层实现逻辑：

• Spring Data JPA：saveAll在同一个事务中同步依次处理每个实体。对于手动构建的脱离持久化上下文的实体，save方法会执行merge操作——先查询数据库获取当前最新的实体状态（包括最新版本号），再将传入实体的属性覆盖到这个状态上，最后执行更新。因此处理第二个实体时，会自动使用前一个操作更新后的版本号，不会出现版本不匹配的问题。
• Spring Data R2DBC：saveAll会按顺序异步处理每个实体，但每个save操作完全依赖传入实体自身的@Version属性值执行乐观锁校验。第一个实体更新后，数据库中的版本号已经自增，但第二个实体的version属性依然是初始的1L，此时执行更新就会触发乐观锁校验失败，抛出异常。

三、相关文档说明 #

关于两种Repository的saveAll行为，官方文档有明确的对应说明：

• Spring Data JPA：官方文档中提到，save方法对于脱离持久化上下文的实体（非从数据库加载的实例）会执行merge逻辑，该逻辑延伸到saveAll，会自动处理实体与数据库状态的同步，包括版本号的更新。
• Spring Data R2DBC：官方文档中明确，save方法执行更新时，会直接使用传入实体的@Version值作为乐观锁条件，saveAll会逐个执行这些save操作，若前序操作修改了数据库中的版本，后续同ID实体的更新会因为版本不匹配触发乐观锁异常。

备注：内容来源于stack exchange，提问作者Mikhail Geyer