先决条件 – 两阶段锁定协议 (2-PL) 的基础知识，2-PL 的类型。
现在，我们知道 Strict 2-PL 和 Rigorous 2-PL 都避免了级联回滚并确保了 Strict 调度，但仍然不能保证我们的调度没有死锁。我们已经看到 Strict 和 Rigorous 2-PL 在应用上是相似的，普遍的误解是保守 2-PL 也遵循与上述两个相同的协议集。为了清楚起见，让我们详细介绍一下保守党 2-PL。
保守党 2-PL –
AKA Static 2-PL ，该协议要求事务在事务开始执行之前通过预先声明其读取集和写入集来锁定它访问的所有项目。如果无法锁定所需的任何预先声明的项目，则事务不会锁定任何项目，而是等待所有项目都可用于锁定。所以在我们锁定所有需要的项目之前，不能开始对数据的操作。
现在让我们看一个关于 Conservative 2-PL 的有趣例子。告诉我以下时间表是否遵循保守党 2-PL?
Schedule: Lock-X(A) Lock-X(B) Read(A) Read(B) Write(A) Unlock(A) Commit Unlock(B)您认为上述附表不遵循保守党 2-PL 吗?不要将协议混淆为Rigorous 2-PL的修改版，我们可以随时释放锁，但我们需要在执行任何操作之前锁定所有数据项。这就是使它无死锁的原因。上述时间表遵循保守党 2-PL。
保守党 2-PL 的一些有趣特征：
- 在此之后的时间表不会有我们在 Basic、Strict 和 Rigorous 2-PL 中看到的成长阶段。由于在使用之前锁定数据是强制性的，因此该协议没有成长阶段。此外，此规则使其无死锁，就好像某项不可用于锁定事务一样，释放所有锁并稍后再试，即没有 Hold 和 Wait 。这使得死锁的四个必要条件之一无效。
- 我们只需要事先锁定所有项目，因此释放或解锁它们没有我们在 Strict 或 Rigorous 2-PL 中的限制。
- 由于在获取所有锁之前没有进行任何操作，因此与 Basic、Strict、Rigorous 2-PL 不同，我们在此协议中没有 Growing 阶段。
- 尽管我们在此协议中获得了无死锁时间表，但我们仍可能面临级联回滚等缺点。所以这个协议并不能确保 Strict Schedules 。与 Strict 和 Rigorous 2-PL 相比，这是一个劣势。
现在让我们讨论一个例子。看看下面的时间表如何遵循保守 2-PL 但不遵循严格和严格 2-PL。
| T1 | T2 | |
|---|---|---|
| 1 |
Lock-X(A) | |
| 2 | Lock-X(B) | |
| 3 | Read(A) | |
| 4 | *operation on A | |
| 5 | Write(A) | |
| 6 | Unlock(A) | |
| 7 | Lock-X(A) | |
| 8 | Read(A) | |
| 9 | *operation on A | |
| 10 | Write(A) | |
| 11 | Unlock(A) | |
| 12 | Read(B) | |
| 13 | *operation on B | |
| 14 | Write(B) | |
| 15 | Unlock(B) | |
| 16 | Commit | |
| 17 | Commit |
看schedule，完全遵循Conservative 2-PL，但不符合Strict and Rigorous 2-PL的要求，因为我们在事务提交前解锁了A和B。
在保守党 2-PL 中如何发生级联中止?
这可能是因为一个事务可能会从另一个事务执行脏读。我们的协议中没有这样的限制，所以这种情况是可能的。
看看上面给出的例子，我们在第 8 步有一个从 T 1到T 2的脏读操作。如果 T 1中止，那么T 2将被回滚。
GATE 相关问题：
GATE-CS-2016(套装1)|第 61 题