交易最佳做法
我们在多大程度上依赖数据库事务？
我们喜欢小型还是大型交易范围？
我们是否比服务器更喜欢客户端事务处理(例如.NET中的TransactionScope)？
附带交易，反之亦然？
嵌套交易呢？
我们有一些与交易有关的提示和技巧吗？
我们在处理事务时遇到任何陷阱吗？
欢迎各种答案。
解决方案
回答
我对数据库的每次写操作都使用事务。
因此，在较大的事务中包装了许多小的"事务"，并且基本上在嵌套代码中有出色的事务计数。如果在终止父级时有任何优秀的子级，则所有子级都会回滚。
我更喜欢在可用的情况下进行客户端事务处理。如果我们只能执行sps或者其他服务器端逻辑工作单元，则服务器端事务很好。
回答
我总是将事务包装在using语句中。
using(IDbTransaction transaction )
{
// logic goes here.
transaction.Commit();
}
一旦交易超出范围，便将其处置。如果事务仍处于活动状态，则会回滚。此行为会使我们无法安全地锁定数据库。即使抛出未处理的异常，事务仍将回滚。
实际上，在我的代码中，我忽略了显式的回滚，而是依靠using语句为我完成工作。我只明确执行提交。
我发现这种模式已大大减少了记录锁定问题。
回答
就个人而言，开发一个基于高流量性能的网站，在任何可能的情况下，我都会远离数据库事务。显然，它们是必需的，因此我使用ORM和页面级对象变量来最大程度地减少必须进行的服务器端调用的次数。
嵌套事务是最小化呼叫的一种绝妙方法，我会尽可能地朝着这个方向发展，只要它们是不会导致锁定的快速查询即可。在这些情况下，NHibernate是一个救星。
回答
哇！有很多问题！
直到一年前，我还是100％依靠交易。现在只有98％。在高流量网站(如提到的Sara)以及高分区数据的特殊情况下，由于需要分布式事务，因此可以采用无事务架构。现在，我们必须在应用程序中编写引用完整性的代码。
另外，我喜欢使用注释(我是Java专家)和方面来声明式管理事务。这是确定事务边界的一种非常干净的方法，它包括事务传播功能。
回答
这是嵌套T-SQL事务的有趣链接：http://aleemkhan.wordpress.com/2006/07/21/t-sql-error-handling-pattern-for-nested-transactions-and-stored-procedures/
回答
就像FYI ...嵌套交易可能很危险。它只是增加了陷入僵局的机会。因此，尽管它是好的而且必要的，但是在大批量情况下，它的实现方式很重要。
回答
正如Sara Chipps所说，对于高流量的应用程序来说，交易是多余的。因此，我们应尽可能避免使用它。换句话说，我们使用BASE架构而不是ACID。易趣是一个典型的例子。在Ebay架构中根本不使用分布式事务。但是为了最终的一致性，我们必须自己做一些技巧。
回答
服务器端事务，每秒35,000个事务，SQL Server：从35,000 tps中吸取10节
我们仅使用服务器端事务：
- 可以稍后开始，尽早完成
- 未分配
- 可以做之前和之后的工作
- SET XACT_ABORT ON表示立即回滚错误
- 客户端/操作系统/驱动程序无关
其他：
- 我们嵌套调用，但使用@@ TRANCOUNT来检测已启动的TXN
- 每个数据库调用始终是原子的
我们每天处理数百万条INSERT行(有些是通过登台表进行批处理的)，完整的OLTP，没有问题。虽然不是35k tps。
