Oracle 5.0 Reference Manual page 1138

and implicit commits. For example,
See Section 13.7.6.2,
• Other statements that implicitly cause transactions to be committed do not release existing table
locks. For a list of such statements, see
• The correct way to use
tables, is to begin a transaction with
InnoDB
followed by
explicitly. For example, if you need to write to table
SET autocommit=0;
LOCK TABLES t1 WRITE, t2 READ,
COMMIT;
UNLOCK TABLES;
When you call
own table lock.
its table lock, you have to call
because then
and deadlocks can very easily happen.
autocommit = 1
•
ROLLBACK
13.3.5.2.
LOCK TABLES
If you lock a table explicitly with
• The locks are taken as the same time as those acquired explicitly with the
• The lock on a table used in a trigger depends on whether the table is used only for reading. If so, a
read lock suffices. Otherwise, a write lock is used.
• If a table is locked explicitly for reading with
because it might be modified within a trigger, a write lock is taken rather than a read lock. (That is, an
implicit write lock needed due to the table's appearance within a trigger causes an explicit read lock
request for the table to be converted to a write lock request.)
Suppose that you lock two tables,
LOCK TABLES t1 WRITE, t2 READ;
If or have any triggers, tables used within the triggers will also be locked. Suppose that
t1 t2
trigger defined like this:
CREATE TRIGGER t1_a_ins AFTER INSERT ON t1 FOR EACH ROW
BEGIN
UPDATE t4 SET count = count+1
WHERE id = NEW.id AND EXISTS (SELECT a FROM t3);
INSERT INTO t2 VALUES(1, 2);
END;
The result of the
statement, and
• is locked for writing per the
t1
• is locked for writing, even though the request is for a
t2
inserted into within the trigger, so the
• is locked for reading because it is only read from within the trigger.
t3
• is locked for writing because it might be updated within the trigger.
t4
LOCK TABLES
"FLUSH Syntax".
LOCK TABLES
TABLES, and to not call
LOCK
...;... do something with tables t1 and t2 here ...
LOCK TABLES, InnoDB
releases its internal table lock at the next commit, but for MySQL to release
InnoDB
UNLOCK
releases its internal table lock immediately after the call of
InnoDB
[436], to help old applications avoid unnecessary deadlocks.
does not release table locks.
and Triggers
LOCK
t1
statement is that
LOCK TABLES
and are locked because they are used within the trigger:
t3 t4
WRITE
and
UNLOCK TABLES
START TRANSACTION
Section 13.3.3, "Statements That Cause an Implicit
and
UNLOCK TABLES
SET autocommit = 0
UNLOCK TABLES
and read from table t2, you can do this:
t1
internally takes its own table lock, and MySQL takes its
TABLES. You should not have
does not acquire the internal table lock at all if
InnoDB
TABLES, any tables used in triggers are also locked implicitly:
TABLES, but needs to be locked for writing
LOCK
and t2, using this statement:
and
t1 t2
lock request.
READ
request is converted to a
READ
1118
Syntax
does not release the global read lock.
with transactional tables, such as
(not
START
until you commit the transaction
autocommit = 1
LOCK TABLES
are locked because they appear in the
lock. This occurs because
request.
WRITE
Commit".
TRANSACTION)
[436],
LOCK TABLES,
statement.
has a
t1
is
t2