使用事务的Dapper抛出“存在未关闭的DataReader”异常求助

核心问题分析 #

你遇到的InvalidOperationException（提示“存在与此命令关联的未关闭DataReader，必须先将其关闭”），根源主要有两个：

1. Dapper延迟枚举导致DataReader未释放：Dapper的QueryAsync<T>返回延迟加载的IEnumerable<T>，如果不主动枚举（比如转成列表、调用Single()/ToList()），DataReader会保持打开状态，后续复用同一连接时就会触发冲突。
2. EF DbConnection与Dapper的共用冲突：EF的DbConnection由EF内部管理，可能被用于变更追踪、延迟加载等操作，和Dapper共用同一连接时，容易出现连接状态不一致的情况，尤其是在事务场景下。

另外代码里存在明确风险点：循环内的QueryAsync调用仅做了await但未枚举结果，导致DataReader长期占用连接。

针对性修复步骤 #

1. 强制枚举所有Dapper查询结果 #

修改循环内的代码，确保QueryAsync的结果被立即枚举，同时修复SQL语法错误：

for (int i = 0; i < tasks.Sum(o => o.ItemCount * o.Required); i++)
{
    // 用Single()确保结果被枚举，同时验证插入成功返回唯一ID
    var taskId = (await conn.QueryAsync<int>(@"
INSERT Task (JobId, Cost) VALUES (@jobId, @Cost)
SELECT CAST(SCOPE_IDENTITY() as int)
    ", new { jobId, job.Cost }, transaction.UnderlyingTransaction)).Single();
}

同时确认所有QueryAsync调用都已正确枚举结果：比如workItemId用了SingleOrDefault()、allocatedTasks用了AsList()，这些逻辑可以保留，它们已经处理了DataReader的关闭。

2. 改用独立SqlConnection替代EF连接 #

彻底避免EF和Dapper共用连接的冲突，创建独立连接用于Dapper事务操作：

public async Task<int> LinkJob(int customerId, int jobId, int employeeId, List<TaskDto> tasks)
{
    // 从EF连接字符串创建独立的SqlConnection
    using (var conn = new SqlConnection(_context.Database.Connection.ConnectionString))
    {
        await conn.OpenAsync();

        using (var transaction = conn.BeginTransaction())
        {
            try
            {
                // 所有Dapper操作都使用这个独立连接和事务
                var checks = await conn.QueryMultipleAsync(@"...", new { customerId, jobId }, transaction);

                // 后续业务逻辑保持不变，仅将transaction.UnderlyingTransaction改为transaction
                var customer = (await checks.ReadAsync<int?>()).SingleOrDefault();
                // ... 其余业务代码

                transaction.Commit();
                return workItemId;
            }
            catch
            {
                transaction.Rollback();
                throw;
            }
        }
    }
}

3. 可选临时方案：开启MultipleActiveResultSets（MARS） #

如果暂时无法修改连接逻辑，可以在数据库连接字符串中添加MultipleActiveResultSets=True，允许同一连接上存在多个活跃的DataReader。但这只是临时 workaround，不能替代上述根本修复，它可能掩盖其他连接管理问题。

关于偶发异常与15分钟无法操作的说明 #

• 偶发原因：只有当未关闭的DataReader占用连接，且后续操作复用该连接时才会触发异常，大部分情况下连接可能被及时回收，所以不常出现。
• 15分钟无法操作：异常发生时，事务可能未正确回滚，或者连接被挂起占用资源，直到数据库连接超时（通常默认15分钟）后才会释放，导致客户无法重新执行操作。修复上述问题后，事务回滚逻辑会更可靠，资源能及时释放。

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