神秘的 SIX 锁，第 1 部分

核心提示： 假设包含我们的表的表空间在定义时使用了 LOCKSIZE PAGE，我有一个程序，神秘的 SIX 锁，第 1 部分(2)，它必须在没有其他人执行维护的情况下运行，我希望这个程序是执行 INSERT、UPDATE、DELETE 和 MERGE 的惟一程序，因为我的程序与其他程序共享数据，所以它必须

假设包含我们的表的表空间在定义时使用了 LOCKSIZE PAGE。我有一个程序，它必须在没有其他人执行维护的情况下运行。我希望这个程序是执行 INSERT、UPDATE、DELETE 和 MERGE 的惟一程序。但是，如果其他程序执行读操作，并不会影响我的程序。允许 SELECT 和只读的 CURSOR。如何实现这个场景呢？

我打算这样做：我将用自己的锁规则覆盖表空间的页级锁规则。在我的程序的初始化阶段，向 DB2 发出 LOCK TABLE mytablename IN SHARE MODE 语句。这个语句让 DB2 获得表空间（建筑物）上的 IS 锁和表（楼层）上的 S 锁。表上的 S 锁允许其他用户执行读操作。实际上，S 锁允许我与两种用户共享数据：使用三级 IS/IS/S 协议只执行读操作的用户，以及发出 LOCK TABLE ... IN SHARE MODE 语句的用户。但是我更愿意与前者共享数据。现在停一下，我们来看看是否能够解决这个问题。

我需要在您执行读操作时执行维护

请记住，在我的程序运行时，它不但要执行读操作，还要执行维护。我希望确保别人不会以 SHARE 模式锁住整个表，否则就无法执行维护。我不能以 EXCLUSIVE 模式锁住这个表，否则在我的程序运行时别人就无法执行读操作。这种进退两难的局面可以通过 SIX 锁来解决。我们来看看幕后发生的情况。

通过发出 LOCK TABLE 语句，我获得了表空间上的 IS 锁和表上的 S 锁。DB2 现在知道不需要为我对这个表的读操作获取页锁。因此，只要我的 LOCK TABLE 语句仍然有效，我就没有任何页级 S 锁。但是，我最终会执行第一个维护操作（INSERT）。请记住，我并没有以 EXCLUSIVE 模式锁住这个表，仅仅采用了 SHARE 模式。因此，执行维护的 SQL 语句必须在页级获得 X 锁。因为我的程序与其他程序共享数据，所以它必须获得 X 页锁，从而警告其他读者它们可能会读取未提交或 “脏的” 数据。