Oracle 5.0 Reference Manual page 1288

• Consistent read does not work over
temporary copy of the original table and deleting the original table when the temporary copy is
built. When you reissue a consistent read within a transaction, rows in the new table are not visible
because those rows did not exist when the transaction's snapshot was taken.
uses a consistent read for select in clauses like
InnoDB
(SELECT), and
if the
MODE
transaction is not set to
table. Otherwise,
where each consistent read, even within the same transaction, sets and reads its own fresh snapshot.
14.2.7.3.
SELECT ... FOR UPDATE
Reads
In some circumstances, a consistent (nonlocking) read is not convenient and a locking read is required
instead.
InnoDB
•
SELECT ... LOCK IN SHARE MODE
lock enables other sessions to read the rows but not to modify them. The rows read are the latest
available, so if they belong to another transaction that has not yet committed, the read blocks until
that transaction ends.
• For index records the search encounters,
doing
SELECT ... LOCK IN SHARE MODE
Consistent reads will ignore any locks set on the records that exist in the read view. (Old versions of
a record cannot be locked; they will be reconstructed by applying undo logs on an in-memory copy of
the record.)
Locks set by
committed or rolled back.
As an example of a situation in which a locking read is useful, suppose that you want to insert a new
row into a table child, and make sure that the child row has a parent row in table parent. The
following discussion describes how to implement referential integrity in application code.
Suppose that you use a consistent read to read the table
to-be-inserted child row in the table. Can you safely insert the child row to table child? No, because
it is possible for some other session to delete the parent row from the table
without you being aware of it.
The solution is to perform the
SELECT * FROM parent WHERE NAME = 'Jones' LOCK IN SHARE MODE;
A read performed with
lock on the rows read. A shared mode lock prevents others from updating or deleting the row read.
Also, if the latest data belongs to a yet uncommitted transaction of another session, we wait until that
transaction ends. After we see that the
can safely add the child record to the
Let us look at another example: We have an integer counter field in a table
use to assign a unique identifier to each child added to table child. It is not a good idea to use either
consistent read or a shared mode read to read the present value of the counter because two users
of the database may then see the same value for the counter, and a duplicate-key error occurs if two
users attempt to add children with the same identifier to the table.
Here,
LOCK IN SHARE MODE
time, at least one of them ends up in deadlock when it attempts to update the counter.
In this case, there are two good ways to implement reading and incrementing the counter:
The
InnoDB
CREATE TABLE ... SELECT
innodb_locks_unsafe_for_binlog
SERIALIZABLE
uses stronger locks and the
InnoDB
supports two types of locking reads:
LOCK IN SHARE MODE
SELECT
LOCK IN SHARE MODE
is not a good solution because if two users read the counter at the same
Transaction Model and Locking
because
ALTER TABLE
INSERT INTO ...
that do not specify
[1244]
[1121]. Thus, no locks are set on rows read from the selected
SELECT
and
SELECT ... LOCK IN SHARE MODE
sets a shared mode lock on the rows read. A shared mode
SELECT ... FOR UPDATE
or from reading in certain transaction isolation levels.
and reads are released when the transaction is
FOR UPDATE
parent
in a locking mode using
reads the latest available data and sets a shared mode
LOCK IN SHARE MODE
table and commit our transaction.
child
1268
works by making a
ALTER TABLE
SELECT,
or
FOR UPDATE
option is set and the isolation level of the
part acts like
READ COMMITTED
blocks other sessions from
and indeed see the parent row of the
parent
LOCK IN SHARE MODE:
query returns the parent 'Jones', we
child_codes
UPDATE ...
LOCK IN SHARE
[1121],
Locking
in the meantime
that we