EF Core 乐观并发控制在跟踪实体与未跟踪实体中的差异分析

概述

在使用Entity Framework Core进行数据访问时，乐观并发控制是一种重要的并发处理机制。本文通过一个实际案例，深入分析EF Core中乐观并发控制在跟踪实体(Attached Entity)与未跟踪实体(Detached Entity)上的行为差异，并解释其背后的原理。

乐观并发控制基础

乐观并发控制是EF Core提供的一种并发处理策略，它通过在更新数据时检查数据是否被其他事务修改过来解决并发冲突。在EF Core中，通常通过以下两种方式实现：

1. 使用[Timestamp]特性标记的并发令牌列
2. 使用[ConcurrencyCheck]特性标记的列

在本文案例中，使用的是第一种方式，即通过[Timestamp]标记的RowVersion字段作为并发令牌。

问题现象

开发者发现以下两种场景的行为不一致：

1. 跟踪实体场景：实体从DbContext查询后直接修改并发令牌值，保存时不抛出并发异常
2. 未跟踪实体场景：实体以AsNoTracking()方式查询后附加到上下文，修改并发令牌值后保存时抛出并发异常

技术原理分析

EF Core的并发检查机制

EF Core在执行更新操作时，会将实体的当前值与数据库中该记录的当前值进行比较。具体来说：

1. 对于跟踪实体，EF Core会使用实体被跟踪时的原始值(Original Value)作为并发检查的基准
2. 对于未跟踪实体，当它被附加到上下文时，EF Core会将所有属性的当前值同时设置为原始值和当前值

案例中的关键差异

在跟踪实体场景中：

• 实体被查询后，EF Core记录了原始RowVersion值
• 修改RowVersion只改变了当前值，原始值保持不变
• 保存时EF Core使用原始值进行并发检查，与数据库中的值可能一致，因此不抛出异常

在未跟踪实体场景中：

• 实体以AsNoTracking()方式查询，上下文不跟踪其状态
• 修改RowVersion后附加到上下文，原始值和当前值都被设置为修改后的值
• 保存时EF Core使用修改后的值进行并发检查，与数据库中的值不一致，因此抛出异常

解决方案

要使跟踪实体也能正确触发并发冲突检查，需要显式设置属性的原始值：

context.Entry(widget).Property(w => w.RowVersion).OriginalValue = 123456;

最佳实践建议

1. 在大多数业务场景中，不应直接修改并发令牌的值，而应该让数据库自动生成
2. 如果需要模拟并发冲突进行测试，应确保正确设置原始值
3. 理解EF Core对跟踪实体和未跟踪实体的状态管理差异
4. 在需要重新附加实体时，考虑使用DbContext.Update方法，它会自动将实体状态设置为Modified

总结

EF Core的乐观并发控制机制在跟踪实体和未跟踪实体上的行为差异源于其内部的状态管理方式。理解这种差异对于正确实现并发控制至关重要。开发者应根据实际业务需求选择合适的实体跟踪策略，并确保正确设置并发检查所需的原始值。