The chart below shows the compatibility of different lock mode types:
LOCK THAT IS REQUESTED
| IS | IX | S | SIX | X |
---|------|------|------|------|------|
IS| * | * | * | * | |
LOCK ---|------|------|------|------|------|
THAT IX| * | * | | | |
ALREADY ---|------|------|------|------|------|
EXISTS S| * | | * | | |
---|------|------|------|------|------|
SIX| * | | | | |
---|------|------|------|------|------|
X| | | | | |
COMPATIBLE The second lock request is granted. Both transactions
( * ) are allowed to concurrently access the data object at
the same time.
NOT The second lock request must wait until the lock
COMPATIBLE acquired by the first transaction is released.
( )
Granularity is used when determining compatibility. For example, suppose that
two transactions want to access the same row in a PUBLICROW table. The first
transaction is reading it, the second transaction wants to update it. The
following occurs within ALLBASE/SQL:
First the table level intention locks are compared. The first transaction has
an IS lock at the table level, the second transaction needs an IX lock at the
table level. These two locks are compatible, so the IX table lock is granted.
Next, the page level intention locks are compared. The first transaction has
an IS lock, the second transaction needs an IX lock. Again, these two locks
are compatible, so the IX page lock is granted.
Finally, the row level locks are compared. The first transaction has an S row
lock. The second transaction needs an X row lock. These two lock modes are
not compatible, so the second transaction must wait. However, if the
second transaction had wanted to write to a different row on the same page as
the first row, a different X row lock could have been granted to the second
transaction.
Printable version
