神秘的 SIX 锁，第 1 部分

现在，我处于一种奇怪的状态。我持有表空间上的 IS 锁、表上的 S 锁和页上的 X 锁。这并不合法。如果我有页级 X 锁，就必须设法让别的程序在表和表空间级上知道这一情况。如果放任不管，别人就可以成功地执行 LOCK TABLE mytablename in SHARE MODE 语句（通过请求 IS/S 锁，这些锁与我的 IS/S 锁共享数据）。如果这个语句成功地执行了，那个用户就会误以为目前没有人在这个表上执行维护。那么，我应该怎么做呢？

锁规则

在这里应用三个 DB2 锁规则。规则 1 是，任何人在任何时候在任何实体上只能持有一个锁。规则 2 是，如果一个用户需要单一实体上的两个不同的锁，那么获得的锁是这两个锁中限制较严的那个。规则 3 是，每个锁必须报告可能存在的任何低级锁。

如果我在持有 IS/S 锁的情况下读取一个页上的第一行，那么不需要获得 S 锁。但是，如果我在同一个工作单元中更新同一页上的另一行（比如第五行），或者在刚才读取的同一页上插入一个新行，那么会发生什么情况？这时我需要这个页上的 X 锁。根据规则 1，我（一个用户）在单一实体（在这里，实体是一个页）上只能持有一个锁。根据规则 2，我持有的锁将是两个锁中限制较严的那个。X 锁的限制比 S 锁严得多（换句话说，更不友好）；因此，理论上的 S 锁（“我只执行读操作”）和 X 锁（“我要执行维护”）这两个需求会导致我持有页上的一个 X 锁。

到目前为止，根据规则 1 和 2，我持有表空间上的 IS 锁、表上的 S 锁和页上的 X 锁。但是，还必须实施规则 3。如果只查看高级锁，在这些级上没有任何迹象表明我在页级上持有 X 锁。在表空间级，IS 锁表明可能存在低级的 S 锁，但是它还表明没有低级的 X 锁。如果把表空间 IS 锁升级为 IX 锁，就向别的用户表明我不但可能有低级 S 锁（在这个示例中，是在表级），还可能有低级 X 锁（在这个示例中，是在页级）。这样的话，规则 1、2 和 3 都已经成功地应用于表空间级了。