.NET 5.0下在TransactionScope中多次调用SaveChangesAsync触发PostgreSQL超时异常的求助

我之前处理过类似的EF Core + Npgsql + TransactionScope的超时问题，结合你的技术栈（.NET 5.0、EF Core 5.0.10、Npgsql.EntityFrameworkCore.PostgreSQL 5.0.10）以及补充的细节（移除第二次实体修改就不会超时），这个问题的核心原因是：同一事务内对同一实体的多次更新操作，引发了PostgreSQL的行锁等待超时。

当你第一次调用SaveChangesAsync时，PostgreSQL会对OrderItem行加上排他锁（因为是更新操作），而这个锁会在整个TransactionScope事务完成前一直持有。第二次修改实体并调用SaveChangesAsync时，EF Core会尝试再次更新同一行，此时数据库会等待锁释放，但由于事务还未完成，锁无法释放，最终导致超时。如果不修改实体，第二次SaveChangesAsync没有实际的数据库操作，自然不会触发超时。

下面是几个可行的解决方案：

1. 合并变更，只调用一次SaveChangesAsync #

这是最直接且高效的解决办法——既然你是对同一个实体的多个属性做修改，完全可以合并所有变更后只执行一次保存操作，避免重复的数据库交互和锁冲突：

var transactionOptions = new TransactionOptions();
transactionOptions.IsolationLevel = IsolationLevel.ReadCommitted;
transactionOptions.Timeout = TransactionManager.MaximumTimeout;
using (TransactionScope scope = new TransactionScope(TransactionScopeOption.Required, transactionOptions, TransactionScopeAsyncFlowOption.Enabled))
{
    OrderItem item = await _unitOfWork.OrderItems.FirstOrDefaultAsync(x => x.Id.Equals("123456"));
    // 合并所有修改
    item.IsCanceled = true;
    item.Qty = 0;
    await _unitOfWork.SaveChangesAsync();
    
    // some other code
    
    scope.Complete();
}

2. 解除实体跟踪，重新查询后再修改 #

如果业务逻辑必须分两次保存（比如中间有依赖其他服务的操作），可以在第一次保存后手动解除EF Core对实体的跟踪，然后重新查询实体再进行第二次修改：

var transactionOptions = new TransactionOptions();
transactionOptions.IsolationLevel = IsolationLevel.ReadCommitted;
transactionOptions.Timeout = TransactionManager.MaximumTimeout;
using (TransactionScope scope = new TransactionScope(TransactionScopeOption.Required, transactionOptions, TransactionScopeAsyncFlowOption.Enabled))
{
    OrderItem item = await _unitOfWork.OrderItems.FirstOrDefaultAsync(x => x.Id.Equals("123456"));
    item.IsCanceled = true;
    await _unitOfWork.SaveChangesAsync();
    
    // 解除当前实体的跟踪
    _unitOfWork.OrderItems.Entry(item).State = EntityState.Detached;
    
    // some other code
    
    // 重新从数据库查询实体
    item = await _unitOfWork.OrderItems.FirstOrDefaultAsync(x => x.Id.Equals("123456"));
    item.Qty = 0;
    await _unitOfWork.SaveChangesAsync();
    
    scope.Complete();
}

这样做可以让EF Core获取一个全新的实体跟踪实例，避免和第一次更新的锁产生冲突。

3. 调整数据库超时配置（临时缓解） #

如果上述方案暂时无法实施，可以通过调整Npgsql的命令超时和PostgreSQL的锁超时参数来缓解问题：
在你的DbContext的OnConfiguring方法中添加配置：

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder.UseNpgsql(
        "你的数据库连接字符串",
        o => 
        {
            o.CommandTimeout(60); // 延长EF Core命令超时时间
            o.SetPostgresCommand("SET lock_timeout = '30s';"); // 设置PostgreSQL锁超时时间
        }
    );
}

注意：这只是临时缓解手段，不能从根本上解决锁冲突问题，建议优先采用前两种方案。

4. 确保DbContext在TransactionScope内创建 #

如果你使用依赖注入管理_unitOfWork，要确保它是在TransactionScope内部被解析的——如果_unitOfWork在TransactionScope创建之前就被注入，EF Core可能无法正确加入到事务中，引发异常。可以尝试在TransactionScope内创建服务作用域来获取_unitOfWork：

var transactionOptions = new TransactionOptions();
transactionOptions.IsolationLevel = IsolationLevel.ReadCommitted;
transactionOptions.Timeout = TransactionManager.MaximumTimeout;
using (TransactionScope scope = new TransactionScope(TransactionScopeOption.Required, transactionOptions, TransactionScopeAsyncFlowOption.Enabled))
{
    // 在事务内部创建服务作用域
    using (var serviceScope = _serviceProvider.CreateScope())
    {
        var unitOfWork = serviceScope.ServiceProvider.GetRequiredService<IUnitOfWork>();
        
        OrderItem item = await unitOfWork.OrderItems.FirstOrDefaultAsync(x => x.Id.Equals("123456"));
        item.IsCanceled = true;
        await unitOfWork.SaveChangesAsync();
        
        // some other code
        
        item.Qty = 0;
        await unitOfWork.SaveChangesAsync();
    }
    
    scope.Complete();
}

内容的提问来源于stack exchange，提问作者Kevin V