EF Core提交时连接中断：事务状态未知与重试风险解惑

核心原因：事务提交的网络确认盲区 #

事务的ACID特性确实保证了服务器端的一致性，但跨网络的提交流程存在一个“灰色地带”：当客户端发起COMMIT请求后，服务器完成提交操作，但响应还没返回给客户端时连接中断——此时客户端收到的是“连接失败”的异常，但服务器端的事务已经成功提交了。

这种场景下，客户端无法区分两种情况：

• 服务器还没执行提交就断了，事务已回滚
• 服务器已经执行完提交，只是响应没传回来

Execution Strategy默认行为的风险 #

EF Core的默认Execution Strategy会假设事务已回滚，自动重试整个操作。这时候如果实际事务已经提交，就会导致重复执行：

• 如果操作是不依赖状态的（比如插入带自动生成键的新行），会直接产生重复数据
• 如果操作依赖现有状态（比如更新某条数据的计数），会导致状态不一致（比如计数被加了两次）

示例：插入数据时的重复问题 #

假设你有一个User实体，主键是自增的Id：

public class User
{
    public int Id { get; set; }
    public string Name { get; set; }
}

执行插入操作的代码：

var strategy = context.Database.CreateExecutionStrategy();
await strategy.ExecuteAsync(async () =>
{
    using var transaction = await context.Database.BeginTransactionAsync();
    try
    {
        context.Users.Add(new User { Name = "Alice" });
        await context.SaveChangesAsync();
        await transaction.CommitAsync(); // 连接在此处中断
    }
    catch (Exception)
    {
        await transaction.RollbackAsync();
        throw; // Execution Strategy会捕获异常并重试
    }
});

两种中断场景：

1. 中断发生在服务器执行提交前：服务器收到COMMIT请求但还没执行，连接断了后自动回滚事务。重试时会重新插入Alice，数据库只有一条记录，没问题。
2. 中断发生在服务器执行提交后：服务器已经把Alice插入数据库，正要返回成功响应时连接断了。客户端收到异常，Execution Strategy重试插入，数据库会出现两条Name="Alice"的记录（因为Id是自增的，主键不冲突），造成数据重复。

为什么数据库不会自动回滚？ #

数据库的事务机制是服务器端的原子操作：一旦COMMIT执行完成，事务就永久生效了。服务器无法知道客户端有没有收到响应——如果强制回滚，反而会破坏已经成功提交的事务一致性。这是分布式系统中典型的“单次消息交付”问题，无法通过本地事务解决。

如何避免这类问题？ #

• 使用幂等操作：给业务字段添加唯一约束（比如给User.Name加唯一索引），这样重试时会触发唯一约束异常，不会产生重复数据。
• 记录操作标识：执行操作前生成一个唯一的操作ID，插入数据时同时保存这个ID，重试前先查询该ID是否存在，避免重复执行。
• 自定义Execution Strategy：针对特定数据库（比如SQL Server），可以尝试查询事务状态（但并非所有数据库都支持），再决定是否重试。

内容的提问来源于stack exchange，提问作者Syed Abdullah