EF Core 并发控制：深入理解并发令牌处理机制

并发控制的基本原理

在Entity Framework Core中，并发控制是防止多个用户同时修改同一数据时产生冲突的重要机制。EF Core通过并发令牌（ConcurrencyStamp）实现乐观并发控制，这种机制允许系统检测并发冲突并在保存时抛出异常。

典型并发场景分析

考虑一个典型的产品管理系统场景：

1. 用户A获取产品信息，包含并发令牌值"0x8890"
2. 用户B同时获取相同产品并修改名称，导致数据库中的并发令牌更新为"0x8891"
3. 用户A尝试提交修改时，系统应检测到并发冲突

两种实现方式的比较

直接附加实体方式

第一种实现方式直接将DTO映射为实体并附加到DbContext：

var entityToUpdate = new Product {
    Id = dto.Id,
    ConcurrencyStamp = dto.ConcurrencyStamp
    // 其他属性...
};
DbContext.Update(entityToUpdate);

这种方式会产生以下SQL：

UPDATE Products SET Name='New' 
WHERE Id=27 AND ConcurrencyStamp=0x8890

优点：能正确检测并发冲突 缺点：

1. 会更新所有属性，即使未修改
2. 无法区分哪些属性真正被修改
3. 可能导致数据丢失（未包含在DTO中的属性会被覆盖）

先查询再修改方式

第二种实现方式先查询实体再修改属性：

var entityToUpdate = await DbContext.Products.FindAsync(dto.Id);
entityToUpdate.Name = dto.Name;
entityToUpdate.ConcurrencyStamp = dto.ConcurrencyStamp;

这种方式会产生以下SQL：

UPDATE Products SET Name='New' 
WHERE Id=27 AND ConcurrencyStamp=0x8891

优点：

1. 只更新真正修改的属性
2. 保留未包含在DTO中的属性值
3. 可以准确检测属性修改状态

缺点：无法正确检测并发冲突（使用了查询时的令牌值而非原始值）

解决方案与最佳实践

针对第二种方式的并发问题，可以采用以下解决方案：

手动设置原始值

DbContext.Entry(entityToUpdate)
    .OriginalValues
    .SetValues(new { ConcurrencyStamp = dto.ConcurrencyStamp });

这种方法明确告诉EF Core使用客户端提供的原始令牌值进行并发检查。

重写SaveChanges方法

更系统化的解决方案是重写SaveChanges方法，自动处理所有并发令牌：

public override async Task<int> SaveChangesAsync(CancellationToken ct)
{
    ChangeTracker.DetectChanges();
    
    foreach (var entry in ChangeTracker.Entries()
        .Where(e => e.State == EntityState.Modified))
    {
        if (entry.CurrentValues.TryGetValue<byte[]>("ConcurrencyStamp", out var stamp))
        {
            entry.OriginalValues["ConcurrencyStamp"] = stamp;
        }
    }
    
    return await base.SaveChangesAsync(ct);
}

设计思考与建议

1. 并发令牌处理策略：EF Core默认使用原始值进行并发检查，这是为了支持应用管理的并发令牌场景

2. 性能考量：在检测到并发令牌不匹配时，可以直接抛出异常而无需执行数据库操作

3. 混合模式考虑：对于某些场景，可能需要同时考虑原始值和当前值进行更复杂的冲突检测

4. DTO设计建议：确保DTO包含所有必要字段，避免数据丢失问题

总结

EF Core的并发控制机制提供了灵活的方式来处理数据冲突。理解并发令牌的工作原理和不同实现方式的优缺点，可以帮助开发者根据具体业务场景选择最合适的实现方式。对于断开连接的实体更新场景，手动设置原始并发令牌值或重写SaveChanges方法都是有效的解决方案。