您对数据库事务的依赖程度如何？
您喜欢小交易范围还是大交易范围？
您是否更喜欢客户端事务处理（例如 .NET 中的 TransactionScope）而不是服务器端事务，反之亦然？
嵌套事务呢？
你有一些与交易有关的提示和技巧吗？
您在使用事务时遇到的任何问题？
欢迎各种答案。
aku
问问题
15086 次
8 回答
21
我总是将事务包装在 using 语句中。
using(IDbTransaction transaction )
{
// logic goes here.
transaction.Commit();
}
一旦事务超出范围，它就会被处理掉。如果事务仍处于活动状态，则回滚。此行为可防止您意外锁定数据库。即使抛出未处理的异常，事务仍然会回滚。
在我的代码中，我实际上省略了显式回滚并依靠 using 语句为我完成工作。我只明确执行提交。
我发现这种模式大大减少了记录锁定问题。
于 2008-09-02T14:08:27.137 回答
8
就个人而言，开发一个基于高流量性能的网站，我尽可能远离数据库事务。显然它们是必需的，所以我使用 ORM 和页面级对象变量来最小化我必须进行的服务器端调用的数量。
嵌套事务是一种极好的方式来最小化您的调用，只要它们是不会导致锁定的快速查询，我就会尽可能地朝着这个方向前进。NHibernate 在这些情况下一直是救星。
于 2008-09-02T14:10:56.210 回答
3
仅供参考……嵌套事务可能很危险。它只会增加陷入僵局的机会。因此，尽管它是好的和必要的，但它的实施方式在更高容量的情况下很重要。
于 2008-09-05T14:45:35.430 回答
3
我对数据库的每个写操作都使用事务。
因此，在一个较大的事务中包含相当多的小“事务”，基本上嵌套代码中有一个未完成的事务计数。如果您结束父级时有任何未完成的子级，则其全部回滚。
我更喜欢可用的客户端事务处理。如果您被降级为执行 sps 或其他服务器端逻辑工作单元，则服务器端事务很好。
于 2008-09-02T14:04:09.347 回答
3
哇！很多问题！
直到一年前，我还 100% 依赖交易。现在只有 98%。在高流量网站（如 Sara 提到的）和高分区数据的特殊情况下，强制执行分布式事务的需要，可以采用无事务架构。现在您必须在应用程序中编写参照完整性代码。
此外，我喜欢使用注释（我是 Java 人）和方面以声明方式管理事务。这是确定事务边界的一种非常简洁的方法，它包括事务传播功能。
于 2008-09-02T15:53:36.073 回答
2
服务器端事务，每秒 35,000 个事务，SQL Server：35K tps 的 10 节课
我们只使用服务器端事务：
- 可以晚一点开始，早一点结束
- 未分发
- 可以在之前和之后工作
- SET XACT_ABORT ON 表示出错时立即回滚
- 客户端/操作系统/驱动程序不可知
其他：
- 我们嵌套调用但使用@@TRANCOUNT 来检测已经启动的 TXN
- 每个数据库调用始终是原子的
我们每天处理数百万个 INSERT 行（一些通过临时表进行批处理），完整的 OLTP，没有问题。虽然不是 35k tps。
于 2009-10-16T15:40:54.167 回答
0
这是嵌套 T-SQL 事务的一个有趣链接：http: //aleemkhan.wordpress.com/2006/07/21/t-sql-error-handling-pattern-for-nested-transactions-and-stored-procedures/
于 2008-09-05T14:32:19.940 回答