交易最佳实践[结束]

我总是用using语句包装事务。

using(IDbTransaction transaction )
{
// logic goes here.
   transaction.Commit();
}

一旦事务超出范围,它就会被释放。如果事务仍处于活动状态,则回滚该事务。这种行为会防止意外锁定数据库。即使引发未处理的异常,事务仍将回滚。

在我的代码中,我实际上省略了显式回滚,并依赖using语句来为我做这项工作。我只显式地执行提交。

我发现这种模式大大减少了记录锁定问题。

就个人而言,开发一个基于高流量性能的网站,我尽可能远离数据库事务。显然它们是必要的,所以我使用orm和页面级对象变量来最小化必须进行的服务器端调用的数量。

嵌套事务是最小化调用的一种非常好的方法,只要它们是不会导致锁定的快速查询,我就会尽可能地朝着这个方向前进。在这些案件中,尼伯纳是救世主。

我对数据库的每个写操作都使用事务。
因此,有相当多的小“事务”封装在一个较大的事务中,基本上嵌套代码中有一个未完成的事务计数。如果在结束父项时有任何未完成的子项,则全部回滚。

我更喜欢在可用的情况下进行客户端事务处理。如果您被降级为执行sps或其他服务器端逻辑工作单元,服务器端事务就可以了。

真的!很多问题!

直到一年前,我还是百分之百地依赖交易。现在只有98%。在高流量网站(如sara所述)和高分区数据的特殊情况下,为了满足分布式事务的需要,可以采用无事务架构。现在您必须在应用程序中编写引用完整性代码。

此外,我喜欢使用注释(我是Java家伙)和方面声明性地管理事务。这是一种非常干净的确定事务边界的方法,它包括事务传播功能。

作为参考…嵌套事务可能很危险。这只会增加陷入僵局的机会。因此,虽然它是好的和必要的,但它的实现方式在更大容量的情况下是重要的。

服务器端事务,每秒35000个事务,SQL Server: 10 lessons from 35K tps

我们只使用服务器端事务:

• 可以迟一点开始早一点结束
• 未分发
• 能做前后工作
• 设置xact_abort on表示出错时立即回滚
• 客户端/操作系统/驱动程序不可知

其他:

• 我们嵌套调用,但使用@@trancount检测已启动的txn
• 每个数据库调用总是原子的

我们每天处理数以百万计的插入行(有些是通过临时表批处理的)、完整的oltp,没有问题。但不是3.5万tps。

这是嵌套t-sql事务的有趣链接: http://aleemkhan.wordpress.com/2006/07/21/t-sql-error-handling-pattern-for-nested-transactions-and-stored-procedures/

正如sara chips所说,对于高流量应用程序来说,交易是过度的。所以我们应该尽量避免。换句话说,我们使用 BASE architecture 而不是酸。ebay就是一个典型的例子。eBay体系结构中根本不使用分布式交易。但为了 eventual consistency ,你得自己搞点把戏。