Audit.NET框架中DbContext并发控制问题的分析与解决

背景介绍

在使用Entity Framework Core(EF Core)开发ASP.NET Core应用时，乐观并发控制是保证数据一致性的重要机制。EF Core通过RowVersion字段和DbUpdateConcurrencyException异常来实现这一功能。然而，当开发者使用Audit.NET框架的AuditDbContext时，可能会遇到并发控制失效的问题。

问题现象

在标准EF Core应用中，当两个用户同时尝试更新同一条记录时，后提交的用户会因为RowVersion不匹配而收到DbUpdateConcurrencyException异常。这是EF Core的预期行为，确保了数据的并发安全。

但当DbContext继承自Audit.EntityFramework.AuditDbContext后，这一机制出现了异常：

1. 并发更新时不再抛出DbUpdateConcurrencyException
2. 更新操作被静默接受，导致数据一致性风险
3. 回退到标准DbContext后，并发控制又恢复正常

原因分析

Audit.NET框架的AuditDbContext通过重写EF Core的保存行为来实现审计功能。其中关键的影响因素是ReloadDatabaseValues配置项：

• 当ReloadDatabaseValues设置为true时(默认值)，AuditDbContext会在更新前从数据库重新加载实体值
• 这一重加载过程会刷新RowVersion值，使得并发检查总是通过
• 因此EF Core的原生并发控制机制被绕过

解决方案

方案一：调整Audit.NET配置

最简单的解决方案是在Audit.NET配置中显式设置ReloadDatabaseValues为false：

Audit.EntityFramework.Configuration.Setup()
    .ForContext<YourDbContext>(config => config
        .ReloadDatabaseValues(false));

这样配置后，AuditDbContext将不再自动刷新实体值，EF Core的并发控制机制将恢复正常。

方案二：自定义并发检查

如果业务上确实需要保持ReloadDatabaseValues为true，可以手动实现并发检查：

public async Task UpdateEntityAsync(YourEntity entity)
{
    var existing = await _context.YourEntities
        .AsNoTracking()
        .FirstOrDefaultAsync(e => e.Id == entity.Id);
        
    if(existing.RowVersion != entity.RowVersion)
    {
        throw new ConcurrencyException("数据已被其他用户修改");
    }
    
    _context.Update(entity);
    await _context.SaveChangesAsync();
}

方案三：混合模式

对于需要审计但又严格要求并发控制的场景，可以考虑：

1. 使用标准DbContext进行写操作
2. 通过拦截器或中间件单独记录审计日志
3. 这样既能保留EF Core的并发控制，又能实现审计需求

最佳实践建议

1. 明确需求：首先确定应用对并发控制和审计的需求优先级
2. 测试验证：在开发环境中充分测试并发场景
3. 监控报警：生产环境中监控并发冲突事件
4. 文档记录：在团队文档中明确记录采用的并发策略

总结

Audit.NET是一个功能强大的审计框架，但在与EF Core的并发控制机制集成时需要特别注意配置。理解框架底层的工作原理，合理配置ReloadDatabaseValues选项，可以确保审计功能和并发控制两者兼顾。对于关键业务系统，建议采用方案三的混合模式，既能满足审计合规要求，又能保证数据一致性。