Oracle 5.0 Reference Manual page 1285

In row-level locking,
can also lock the "gap" preceding an index record to block insertions by other sessions in the
InnoDB
gap immediately before the index record. A next-key lock refers to a lock that locks an index record and
the gap before it. A gap lock refers to a lock that locks only the gap before some index record.
For more information about row-level locking, and the circumstances under which gap locking is
disabled, see
14.2.7.1. Lock Modes
InnoDB
implements standard row-level locking where there are two types of locks:
InnoDB
• A shared (S) lock permits a transaction to read a row.
• An exclusive (X) lock permits a transaction to update or delete a row.
If transaction
a lock on row
• A request by
on r.
• A request by
If a transaction
for a lock of either type on
transaction
Additionally,
and locks on entire tables. To make locking at multiple granularity levels practical, additional types
of locks called intention locks are used. Intention locks are table locks in InnoDB. The idea behind
intention locks is for a transaction to indicate which type of lock (shared or exclusive) it will require later
for a row in that table. There are two types of intention locks used in
has requested a lock of the indicated type on table t):
T
• Intention shared (IS): Transaction
• Intention exclusive (IX): Transaction
For example,
sets an lock.
IX
The intention locking protocol is as follows:
• Before a transaction can acquire an
lock on t.
• Before a transaction can acquire an
These rules can be conveniently summarized by means of the following lock type compatibility matrix.
X
IX
S
IS
A lock is granted to a requesting transaction if it is compatible with existing locks, but not if it conflicts
with existing locks. A transaction waits until the conflicting existing lock is released. If a lock request
conflicts with an existing lock and cannot be granted because it would cause deadlock, an error occurs.
The
InnoDB
normally uses next-key locking. That means that besides index records,
InnoDB
Section 14.2.7.4, "InnoDB
holds a shared (S) lock on row r, then requests from some distinct transaction
T1
are handled as follows:
r
for an lock can be granted immediately. As a result, both
T2 S
for an lock cannot be granted immediately.
T2 X
holds an exclusive (X) lock on row r, a request from some distinct transaction
T1
cannot be granted immediately. Instead, transaction
r
to release its lock on row r.
T1
supports multiple granularity locking which permits coexistence of record locks
InnoDB
SELECT ... LOCK IN SHARE MODE
X
Conflict
Conflict
Conflict
Conflict
Transaction Model and Locking
Record, Gap, and Next-Key
intends to set locks on individual rows in table t.
T S
intends to set locks on those rows.
T X
sets an
lock on a row in table t, it must first acquire an
S
lock on a row, it must first acquire an
X
IX
Conflict
Compatible
Conflict
Compatible
1265
Locks".
and
T1
T2
(assume that transaction
InnoDB
lock and
IS SELECT ... FOR UPDATE
lock on t.
IX
S IS
Conflict Conflict
Conflict Compatible
Compatible Compatible
Compatible Compatible
for
T2
hold an lock
T2 S
T2
has to wait for
or stronger
IS