事务与锁的探讨－应用锁

应用锁是我个人起的名字，我想表达的意思是：

1. A 获取一笔订单，订单显示未付款（未付款订单可以关闭，已付款订单不能关闭）。
2. B 对该笔订单付款。
3. A 关闭该笔订单。

好了，出现问题了，对 A 来说它是按正常程序关闭订单，对于 B 来说它是按正常程序付款，可是最终的结果却是关闭了已付款订单。

所以我们就得用事务与锁来解决问题。

我们强制为第 1 步增加一个更厉害的锁，让执行顺序变成 1、3、2。有人说，这不一样么？只不过之前是关闭了已付款订单，现在是对已关闭订单付了款。

那就在付款前再读取一次订单，看看是不是已经关闭，已经关闭就不付款。

这种看似解决了，但实际带来几个问题：

• 人工加锁，导致程序很混乱，付款那里增加的再读取一次订单是否关闭，也得加锁，A 和 B 都有锁，再有其他业务进来，就更乱了，搞不好就造成死锁了。
• 人工加锁，设计得不好，效率还很低。
• 有些业务上没办法加锁，假如第 1 步是获取记录显示在客户端浏览器上，怎么锁？

有一种处理方法就是我说的应用锁，个人起的名字，其实跟“锁”没半毛钱关系，只是实现类似功能。

就是增加一个 timestamp 类型的列，每当记录更新，这个列的值都会自动增加，我们只需要判断这个列的值有没有变化，就知道这前后有没有其他人来更新了。

相关阅读

• timestamp 与 rowversion
• timestamp 详解
• 利用 timestamp 避免更新冲突
• 如何显示timestamp的值
• SQL Server中timestamp（时间戳）