Lock type compatibility
Lock compatibility becomes an issue when one application holds a lock on an object and another application requests a lock on the same object. When the two lock modes are compatible, the request for a second lock on the object can be granted.
If the lock mode of the requested lock is not compatible with the lock that is already held, the lock request cannot be granted. Instead, the request must wait until the first application releases its lock, and all other existing incompatible locks are released.
Table 1 shows which
lock types are compatible (indicated by a yes) and which types
are not (indicated by a no). Note that a timeout can occur
when a requestor is waiting for a lock.
State of Held Resource | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
State Being Requested | None | IN | IS | NS | S | IX | SIX | U | X | Z | NW |
None | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes |
IN (Intent None) | yes | yes | yes | yes | yes | yes | yes | yes | yes | no | yes |
IS (Intent Share) | yes | yes | yes | yes | yes | yes | yes | yes | no | no | no |
NS (Scan Share) | yes | yes | yes | yes | yes | no | no | yes | no | no | yes |
S (Share) | yes | yes | yes | yes | yes | no | no | yes | no | no | no |
IX (Intent Exclusive) | yes | yes | yes | no | no | yes | no | no | no | no | no |
SIX (Share with Intent Exclusive) | yes | yes | yes | no | no | no | no | no | no | no | no |
U (Update) | yes | yes | yes | yes | yes | no | no | no | no | no | no |
X (Exclusive) | yes | yes | no | no | no | no | no | no | no | no | no |
Z (Super Exclusive) | yes | no | no | no | no | no | no | no | no | no | no |
NW (Next Key Weak Exclusive) | yes | yes | no | yes | no | no | no | no | no | no | no |