明确的交易回滚是否必要？

Question

许多例子都提倡显式回滚数据库事务,其方式如下:

using (var transaction = ...)
{
    try
    {
        // do some reading and/or writing here

        transaction.Commit();
    }
    catch (SqlException ex)
    {
        // explicit rollback
        transaction.Rollback();
    }
}

但是,我倾向于这样做:

using (var transaction = ...)
{
    // do some reading and/or writing here

    transaction.Commit();
}

当发生异常时,我只是依赖于未提交的事务的隐式回滚.

依赖这种隐含行为有什么问题吗？有没有人有一个令人信服的理由为什么我不应该这样做？

Answer 1

不,它不是特别需要的,但是我可以想到为什么它可能是一个好主意的两个原因:

• 明晰

有些人可能会争辩说,transaction.Rollback()在什么情况下交易不会被提交,使用更清楚.

• 释放锁

处理事务时,重要的是要意识到某些锁只会在事务回滚或提交时释放.如果您正在使用该using语句,则事务将在事务处理时回滚,但是如果由于某种原因您需要在using块内部执行一些错误处理,则回滚事务(删除锁定)之前可能是有利的.执行复杂/耗时的错误处理.

Answer 2

大多数正确编写的 ADO.NET 连接将回滚未显式提交的事务。所以这并不是绝对必要的。

我看到显式调用的主要好处Rollback()是能够在那里设置断点，然后检查连接或数据库以查看发生了什么。对于代码的未来维护者来说，在不同的执行路径下会发生什么也更清楚。