Oracle 5.0 Reference Manual page 1137

This policy ensures that table locking is deadlock free. There are, however, other things you need to
be aware of about this policy: If you are using a
that MySQL waits for this particular lock until there are no other sessions that want a
the session has gotten the
list, all other sessions wait for the
your application, you should consider converting some of your tables to transaction-safe tables.
Rules for Lock Release
When the table locks held by a session are released, they are all released at the same time. A session
can release its locks explicitly, or locks may be released implicitly under certain conditions.
• A session can release its locks explicitly with
• If a session issues a
existing locks are released implicitly before the new locks are granted.
• If a session begins a transaction (for example, with
is performed, which causes existing locks to be released. (For additional information about
TABLES
the interaction between table locking and transactions, see
Locking and
If the connection for a client session terminates, whether normally or abnormally, the server implicitly
releases all table locks held by the session (transactional and nontransactional). If the client
reconnects, the locks will no longer be in effect. In addition, if the client had an active transaction, the
server rolls back the transaction upon disconnect, and if reconnect occurs, the new session begins with
autocommit enabled. For this reason, clients may wish to disable auto-reconnect. With auto-reconnect
in effect, the client is not notified if reconnect occurs but any table locks or current transaction will have
been lost. With auto-reconnect disabled, if the connection drops, an error occurs for the next statement
issued. The client can detect the error and take appropriate action such as reacquiring the locks or
redoing the transaction. See
13.3.5.1. Interaction of Table Locking and Transactions
LOCK TABLES
•
LOCK TABLES
to lock the tables.
•
UNLOCK TABLES
to acquire table locks. For example, in the following set of statements,
global read lock but does not commit the transaction because no table locks are in effect:
FLUSH TABLES WITH READ LOCK;
START TRANSACTION;
SELECT ... ;
UNLOCK TABLES;
• Beginning a transaction (for example, with
transaction and releases existing table locks.
•
FLUSH TABLES WITH READ LOCK
subject to the same behavior as
LOCK TABLES
lock and is waiting to get the lock for the next table in the lock table
WRITE
WRITE
LOCK TABLES
Transactions".)
Section 20.6.14, "Controlling Automatic Reconnection
Note
If you use
ALTER TABLE
example, if you attempt a second
an error
Table 'tbl_name' was not locked with LOCK
To handle this, lock the table again prior to the second alteration. See also
Section C.5.7.1, "Problems with
and
UNLOCK TABLES
is not transaction-safe and implicitly commits any active transaction before attempting
implicitly commits any active transaction, but only if
LOCK TABLES
and
UNLOCK TABLES
LOW_PRIORITY WRITE
lock to be released. If this becomes a serious problem with
UNLOCK TABLES.
statement to acquire a lock while already holding locks, its
START
on a locked table, it may become unlocked. For
ALTER TABLE
ALTER TABLE".
interact with the use of transactions as follows:
TRANSACTION) implicitly commits any current
START
acquires a global read lock and not table locks, so it is not
and
UNLOCK TABLES
1117
Syntax
lock for a table, it means only
TRANSACTION), an implicit
Section 13.3.5.1, "Interaction of Table
Behavior".
operation, the result may be
LOCK TABLES
UNLOCK TABLES
with respect to table locking
lock. When
READ
UNLOCK
TABLES.
has been used
releases the