Oracle 5.0 Reference Manual page 1286

Thus, intention locks do not block anything except full table requests (for example,
WRITE). The main purpose of
lock a row in the table.
The following example illustrates how an error can occur when a lock request would cause a deadlock.
The example involves two clients, A and B.
First, client A creates a table containing one row, and then begins a transaction. Within the transaction,
A obtains an
mysql> CREATE TABLE t (i INT) ENGINE = InnoDB;
Query OK, 0 rows affected (1.07 sec)
mysql> INSERT INTO t (i) VALUES(1);
Query OK, 1 row affected (0.09 sec)
mysql> START TRANSACTION;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT * FROM t WHERE i = 1 LOCK IN SHARE MODE;
+------+
| i |
+------+
| 1 |
+------+
1 row in set (0.10 sec)
Next, client B begins a transaction and attempts to delete the row from the table:
mysql> START TRANSACTION;
Query OK, 0 rows affected (0.00 sec)
mysql> DELETE FROM t WHERE i = 1;
The delete operation requires an
lock that client A holds, so the request goes on the queue of lock requests for the row and client B
S
blocks.
Finally, client A also attempts to delete the row from the table:
mysql> DELETE FROM t WHERE i = 1;
ERROR 1213 (40001): Deadlock found when trying to get lock;
try restarting transaction
Deadlock occurs here because client A needs an
cannot be granted because client B already has a request for an
release its
S
by B for an
The client returns this error:
ERROR 1213 (40001): Deadlock found when trying to get lock;
try restarting transaction
At that point, the lock request for the other client can be granted and it deletes the row from the table.
14.2.7.2. Consistent Nonlocking Reads
A consistent read means that
database at a point in time. The query sees the changes made by transactions that committed before
that point of time, and no changes made by later or uncommitted transactions. The exception to this
rule is that the query sees the changes made by earlier statements within the same transaction. This
exception causes the following anomaly: If you update some rows in a table, a
latest version of the updated rows, but it might also see older versions of any rows. If other sessions
simultaneously update the same table, the anomaly means that you may see the table in a state that
never existed in the database.
The
InnoDB
and
IX
lock on the row by selecting it in share mode:
S
X
lock. Nor can the lock held by A be upgraded to an
S
lock. As a result,
X InnoDB
InnoDB
Transaction Model and Locking
locks is to show that someone is locking a row, or going to
IS
lock. The lock cannot be granted because it is incompatible with the
lock to delete the row. However, that lock request
X
generates an error for one of the clients and releases its locks.
uses multi-versioning to present to a query a snapshot of the
1266
LOCK TABLES ...
lock and is waiting for client A to
X
lock because of the prior request
X
SELECT
will see the