Database 我应该在事务中包装每个db调用吗？

我编写了TransactionContext类，该类在应用程序层实例化，并向下发送到业务和数据层，允许嵌套事务。现在我必须决定： 1.如果需要，我应该使用显式事务并让每个函数调用事务的begin、commit或rollback吗？ 2.我可以在创建TransactionContext时隐式启动事务，并且只允许嵌套方法回滚

现在，我将使用第二种方法，因为它更容易编码：不用担心每个方法中的开始、提交或回滚，只需在事务上设置回滚标志，只让最上面的方法担心提交或回滚。问题是，我不确定在事务中包装所有数据库流量是否是一个好主意

将所有数据库调用包装到事务中可能产生哪些负面影响

---

我的设置是ASP.NET应用程序和MSSQL服务器数据库。应用程序和数据库可能位于不同的服务器上，如果这是影响决策的因素。

单个SQL语句已经封装在隐式事务中。在需要时使用事务，即在原子操作中更新多个表时。将所有调用包装到数据库不是一个好主意：它可能会导致吞吐量降低和阻塞

尽管SQL Server支持嵌套事务，但它们可能无法按预期工作：

提交内部事务是非常困难的 被SQL Server数据库忽略 引擎。交易是 已提交或基于 会议结束时采取的行动 最外层的交易。如果外部 事务已提交，内部 嵌套事务也会被删除 坚信的如果外部事务是 向后滚动，然后所有内部 交易也会回滚， 不管内部 交易是单独进行的 承诺

参考号：