TransactionScope的使用及遇到的坑

事务的一般使用

我们使用dotnet访问数据库，通常是这么写的（以PostgreSQL为例，其它数据库类似的）：

//其它数据库无非就是NpgsqlConnection换成别的，如SQL Server的SqlConnection
using(NpgsqlConnection conn = new NpgsqlConnection(connString)){
    // conn.Execute("sql...");
}

如果使用事务，就变成：

using(NpgsqlConnection conn = new NpgsqlConnection(connString)){
    using(TransactionScope ts = new TransactionScope(TransactionScopeOption.Required))
        conn.EnlistTransaction(Transaction.Current);
        // conn.Execute("sql1...");
        // conn.Execute("sql2...");
        ts.Complete();
    }
}

这里说明一下：

new TransactionScope()这个动作可能会改变Transaction.Current的值，Transaction.Current是线程相关的，总的来说，在TransactionScope范围内的话，它就有值，否则是null，这个特性会引起一个大坑，因为TransactionScope可能会不经意地提前结束，后面会详细说。
EnlistTransaction这个方法的意思是将conn加入到当前的TransactionScope去，在TransactionScope的范围内，conn的各种对数据库的操作都能够有事务的保证。（BTW：很多DbConnection对象本身有自动Enlist的功能，可以自行研究，这里为了演示清晰，使用手动Enlist方式）
TransactionScope使用Required模式获得时，表示如果当前已经在事务范围内，就不会创建新的事务，也就是说Transaction.Current不会被改变（我们99%都是想要这种情况），只有外围事务不存在时，才会创建新的事务。TransactionScope还有另外两种获得模式：一是RequiredNew，表示新建一个事务，跟外围事务无关；另一是Suppress，表示不使用外围的事务，这样的话对数据库的操作是直接生效的，没在事务的管理范围内，这种情况下得重新打开一个连接来做，否则也会遇到麻烦，后面会提到。

本文代码偏向于写成伪码形式，重理解

嵌套调用

到此问题不大，但考虑下方法嵌套调用的场景。A方法打开数据库操作，且有一个事务，B方法打开数据库操作，也有一个事务，且这个事务中调用了A方法：

让嵌套调用使用同一个连接

先解决一下这个问题：如果A和B都是各自new一个DbConnection出来，那两者使用的并不是同一个数据库连接对象，这可能会带来一些问题。我们99%的情况，都是希望A和B使用同一个数据库连接，上面这种情况，应该是当A发现当前上下文已经有数据库连接的时候，就直接使用数据库连接，而不重新new一个，也就是说，我们做一个线程相关的DbConnection，要做到这点并不难，利用dotnet的ThreadStatic注解即可办到。下面是参考代码：

public static class DbConnManager {
    [ThreadStatic]
    private static DbConnection _contextDbConnection;

    /// <summary>
    /// 尝试从当前线程上下文中获取数据库连接
    /// 如果当前线程上下文中不存在可用的数据库连接，那么创建之并打开
    /// 注意：此方法只能在Service层使用，如果在UI层使用，MVC的异步模式可能会带来意外的结果
    /// </summary>
    /// <param name="conn">要获取的数据库连接(输出值，实际使用时，应当使用这个值)</param>
    /// <param name="connString">数据库连接字符串，默认为DefaultConnString</param>
    /// <returns>如果是第一次创建的数据库连接，会返回数据库连接，否则返回null</returns>
    public static DbConnection GetContextConnectionAndOpen(out DbConnection conn, string connString = null) {
        DbConnection forReturn = null;
        if (_contextDbConnection == null || _contextDbConnection.State != System.Data.ConnectionState.Open) {
            _contextDbConnection = new NpgsqlConnection(connString ?? DefaultConnString);
            _contextDbConnection.Open();
            forReturn = _contextDbConnection;
        }
        conn = _contextDbConnection;
        return forReturn;
    }
}

使用方法如此：

using (DbConnManager.GetContextConnectionAndOpen(out DbConnection conn)) {
    using (TransactionScope ts = new TransactionScope(TransactionScopeOption.Required)) {
        connInner.EnlistTransaction(Transaction.Current);
        //conn.Execute("sql1...")
        //conn.Execute("sql2...")
        ts.Complete();
    }
}

我们全部的程序都使用这样的调用方式，就能确保层级调用使用的都是同一个数据库连接，如上面的例子，B方法会新建一个数据库连接，而到了A方法这边，发现当前上下文已经有数据库连接了，就直接取得当前连接，而不是新建一个，方法返回null，将其包在using中相当于是不起任何作用，所以A方法返回的时候，也不会关闭数据库连接，这是一个挺巧妙的设计。

坑

这是一个大坑，甚至是一个天坑，只是很长一段时间里，我都没意识到。看下面这种情况：

调用A方法时，加了个try-catch，其目的是记录日志。想想看如果A方法真的抛出了异常，会产生什么样的结果？（思考1分钟）

其结果非常出乎预料，sql1和sql2未能成功执行，但sql3成功了。这就打破了我们对事务的预期——原子性，一个TransactionScope中，要不都成功，要不都失败，现在是有的失败有的却成功了，这是为什么？

其原因是A方法的TransactionScope没有执行到Complete，在A方法抛出异常，离开这个using作用域的时候，此TransactionScope被认为是Abort了，当执行回到B方法后，我们观察到Transaction.Current竟然变成了null，（我没去看TransactionScope的源代码，但应该就是TransactionScope的Dispose方法直接或间接干的）也就是说在执行sql3的时候，并没有处于事务当中（尽管代码上看是将它包围起来了），所以它能单独执行成功，而事务没了，B方法的ts.Complete()调用是不起任何作用的，它也不报错。这就给我们造成了事务范围内原子性丧失的假象，简单地说，事务提前结束了，我们没意识到而已。如果没有try-catch，则没有问题，因为sql3不会被执行到。

填坑

如何解决这个问题？我的思路跟前面的“让嵌套调用使用同一个连接”很类似，那就是：我不光要确保嵌套调用使用的是同一个数据库连接，我还要确保自始至终只有一个TransationScope对象，且当外围事务存在时，using所获得的是个null对象，这样A方法抛出异常，脱离using的作用范围时，相当于什么都没干，也就不存在回到了B方法，Transaction.Current变为null的问题了。

我们先要对TransactionScope做一个包装：

    /// <summary>
    /// TSR - Transaction Scope Wrapper
    /// </summary>
    public sealed class Tsr : IDisposable {
        private TransactionScope _scope;
        public Tsr(TransactionScope scope) {
            _scope = scope;
        }
        public void Complete() {
            _scope?.Complete();
        }
        public void Dispose() {
            _scope?.Dispose();
        }
    }

在DbConnManager中再加个方法：

public static class DbConnManager {
    /// <summary>
    /// 使用事务的帮助方法（required方式，就是我们99%的方式，如果不是要用这种方式使用事务，那此方法不适合）
    /// </summary>
    /// <param name="conn">数据库链接</param>
    /// <returns>如果当前上下文已经包含在事务当中，就不再产生新的事务</returns>
    static public Tsr RequireTransactionScope(this DbConnection conn, out Tsr tsr) {
        if (Transaction.Current != null) {
            tsr = new Tsr(null);
            return null;
        }
        TransactionScope scope = new TransactionScope(TransactionScopeOption.Required);
        conn.EnlistTransaction(Transaction.Current);
        tsr = new Tsr(scope);
        return tsr;
    }
}

再使用统一的方法来获得这个Wrapper，如果存在外围事务，这个Wrapper的TransactionScope就是空的，其Complete方法和Dispose方法什么都不会干。使用的套路：

using (DbConnManager.GetContextConnectionAndOpen(out DbConnection conn)) {
    using (conn.RequireTransactionScope(out Tsr ts)) {
        // conn.Execute("sql1...")
        // conn.Execute("sql2...")
        ts.Complete();
    }
}

好，根据这种使用方法，我们分析一下前面B方法调用A方法，A方法抛异常的问题。如果A方法抛的不是数据库的异常，比如这样：

那执行成功的是sql1，sql2_1和sql3，方法A中的ts相当于什么都没干，sql2_2也没被执行，而sql1，sql2_1和sql3组成一个事务，由B方法的ts.Complete()提交，至于这个事务是不是业务上正确的，那就得具体分析了，通常我们要避免捕捉那些我们不能够处理的Exception，这是程序开发的一个原则。

那如果方法A抛出的是数据库的异常（比如违反唯一键约束），这又是怎样的情况呢？数据库的异常，这表明事务已经失败，根据事务的原子性，要么都成功，要么都失败，只要产生了一个数据库异常，那事务肯定是失败的：

sql2_2的执行出错了，这是个数据库错误，由于其调用者试用了try-catch，所以sql3会被执行到，但由于事务已经在sql2_2执行中失败，所以到了sql3的执行这里，肯定失败，sql3的执行会报错，大概这样的错误：current transaction is aborted, commands ignored until end of transaction block，意思是当前事务已经中止，命令将被忽略，直至事务块结束。

这就是我们预期的效果了。顺便说一下我推荐的处理方式：A方法的ArgumentException最好放在最前面，就是各个SQL没被执行之前先统一做参数检验，B方法捕捉有限的A方法返回的异常，而不是捕捉最大的Exception异常类型，根据实际的业务进行处理，如果实在要捕捉数据库的异常，以满足记录特定日志等需求，则加上这样的语句更好一点，因为再往下执行还是会报错的，不如早点结束：

    try{
        A方法();
    }
    catch(Exception ex){
        logger.LogError(ex);
        if(ex is PostgresqlException){ //再次声明：异常处理必须考虑实际业务
            throw;
        }
    }

将异常信息记录到数据库表去

B方法中捕获了A方法的所有异常，并将错误信息记录到数据库中去，有问题吗？（花10秒钟想想）

当然有问题，如果A方法已经出现数据库异常了，那事务就中止了啊，如何再在这个事务中访问数据库？这种记录所有异常的动作在实际的业务场景中还是挺常见的，解决的方法有：

把这个日志记录的动作放到事务范围外
记录到日志文件就行了，不要记到关系型数据库中了
记录到MongoDB这样的文档数据库去，它对日志的处理更加合适
打开一个新的数据库连接并使用新的事务

现在来讲讲最后一种方法，我直接贴代码了：

B方法(){
    using(conn){
        using(ts){
            conn.Execute(sql1);
            try{
                A方法();
            }
            catch(Exception ex){
                //往数据库里记录错误信息
                NpgsqlConnection subConn = new NpgsqlConnection(connStr); 
                using (subConn) {
                    subConn.Open(); //需要手工Open
                    //RequiresNew表示开启一个新的事务，跟外围的事务无关
                    using (TransactionScope tsNew = new TransactionScope(TransactionScopeOption.RequiresNew)) {
                        subConn.EnlistTransaction(Transaction.Current);
                        subConn.Execute("insert into log_table ...");
                        tsNew.Complete(); //得Commit
                    }
                }
                throw; //打断后续执行
            }
            conn.Execute(sql3);
            ts.Complete()
        }
    }
}

这么一来，写日志的这部分代码就是新的连接+新的事务，执行成功没问题的。另一种做法是把TransactionScopeOption.RequiresNew改为TransactionScopeOption.Suppress,这样相当于是屏蔽掉外围的事务，这样也不需要调用Complete，因为没事务。

其它一些说明

可以用TransactionScope指定执行超时时间。比如指定永不超时：

using (TransactionScope ts = new TransactionScope(TransactionScopeOption.Required, new TransactionOptions { Timeout = TimeSpan.Zero })) {
    conn.EnlistTransaction(Transaction.Current);
    conn.Execute(sql);
    ts.Complete();
}

还能用TransactionScope指定事务隔离级别。比如指定事务隔离级别为“可重复读”（默认是“可序列化”）：

using (TransactionScope ts = new TransactionScope(TransactionScopeOption.Required, new TransactionOptions { IsolationLevel = IsolationLevel.RepeatableRead })) {
    conn.EnlistTransaction(Transaction.Current);
    conn.Execute(sql);
    ts.Complete();
}

关于事务隔离级别的更多信息，可以自行找资料看看。

posted @ 2023-02-05 16:48 guogangj 阅读(2490) 评论(2) 编辑收藏举报

刷新页面返回顶部