LOCK TABLES and UNLOCK TABLES Statements •If a session begins a transaction (for example, with  START TRANSACTION ), an implicit  UNLOCK TABLES  is performed, which causes existing locks to be released. (For additional information about the interaction between table locking and transactions, see Interaction of Table Locking and Transactions.) 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 are no longer 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 are 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 Automatic Reconnection Control. Note If you use  ALTER TABLE  on a locked table, it may become unlocked. For example, if you attempt a second  ALTER TABLE  operation, the result may be an error  Table ’ tbl_name ’ was not locked with LOCK TABLES . To handle this, lock the table again prior to the second alteration. See also Section B.3.6.1, “Problems with ALTER TABLE” . LOCK TABLES  and  UNLOCK TABLES  interact with the use of transactions as follows: • LOCK TABLES  is not transaction-safe and implicitly commits any active transaction before attempting to lock the tables. • UNLOCK TABLES  implicitly commits any active transaction, but only if  LOCK TABLES  has been used to acquire table locks. For example, in the following set of statements,  UNLOCK TABLES  releases the global read lock but does not commit the transaction because no table locks are in effect: •Beginning a transaction (for example, with  START TRANSACTION ) implicitly commits any current transaction and releases existing table locks. • FLUSH TABLES WITH READ LOCK  acquires a global read lock and not table locks, so it is not subject to the same behavior as  LOCK TABLES  and  UNLOCK TABLES  with respect to table locking and implicit commits. For example,  START TRANSACTION  does not release the global read lock. See Section 13.7.8.3, “FLUSH Statement” . FLUSH TABLES WITH READ LOCK; START TRANSACTION; SELECT ... ; UNLOCK TABLES; •Other statements that implicitly cause transactions to be committed do not release existing table locks. For a list of such statements, see Section 13.3.3, “Statements That Cause an Implicit Commit” . •The correct way to use  LOCK TABLES  and  UNLOCK TABLES  with transactional tables, such as  InnoDB tables, is to begin a transaction with  SET autocommit = 0  (not  START TRANSACTION ) followed by LOCK TABLES , and to not call  UNLOCK TABLES  until you commit the transaction explicitly. For example, if you need to write to table  t1  and read from table  t2 , you can do this: SET autocommit=0; LOCK TABLES t1 WRITE, t2 READ, ...; ... do something with tables t1 and t2 here ... 2729 Interaction of Table Locking and Transactions