MySQL Lists are EOL. Please join:

List:Commits« Previous MessageNext Message »
From:paul.dubois Date:October 14 2009 2:06pm
Subject:svn commit - mysqldoc@docsrva: r17137 - in trunk: . refman-5.4
View as plain text  
Author: paul
Date: 2009-10-14 16:06:57 +0200 (Wed, 14 Oct 2009)
New Revision: 17137

Log:
 r27174@arctic:  paul | 2009-10-14 09:00:22 -0500
 5.4 does not have transactional locks


Modified:
   trunk/refman-5.4/sql-syntax-transactions.xml

Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - 07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/mysqldoc/trunk:27173
07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/trunk:25547
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:43968
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/trunk:44480
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:45485
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:39036
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/trunk:39546
   + 07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/mysqldoc/trunk:27174
07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/trunk:25547
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:43968
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/trunk:44480
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:45485
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:39036
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/trunk:39546


Modified: trunk/refman-5.4/sql-syntax-transactions.xml
===================================================================
--- trunk/refman-5.4/sql-syntax-transactions.xml	2009-10-14 14:06:49 UTC (rev 17136)
+++ trunk/refman-5.4/sql-syntax-transactions.xml	2009-10-14 14:06:57 UTC (rev 17137)
Changed blocks: 14, Lines Added: 76, Lines Deleted: 601; 25989 bytes

@@ -689,8 +689,7 @@
     <remark role="help-topic" condition="LOCK"/>
 
     <remark role="help-keywords">
-      LOCK UNLOCK TABLES AS READ LOCAL LOW_PRIORITY WRITE IN SHARE
-      EXCLUSIVE MODE NOWAIT
+      LOCK UNLOCK TABLES AS READ LOCAL LOW_PRIORITY WRITE
     </remark>
 
     <remark role="help-syntax"/>

@@ -703,8 +702,6 @@
 <replaceable>lock_type</replaceable>:
     READ [LOCAL]
   | [LOW_PRIORITY] WRITE
-  | IN SHARE MODE [NOWAIT]
-  | IN EXCLUSIVE MODE [NOWAIT]
 
 UNLOCK TABLES
 </programlisting>

@@ -722,19 +719,16 @@
     </para>
 
     <para>
-      MySQL &current-series; supports nontransactional and transactional
-      locks. These are intended for use in nontransactional or
-      transactional context, respectively. Nontransactional locks may be
-      used to emulate transactions or to get more speed when updating
-      tables. This is explained in more detail later in this section.
+      Locks may be used to emulate transactions or to get more speed
+      when updating tables. This is explained in more detail later in
+      this section.
     </para>
 
     <para>
       <literal role="stmt">LOCK TABLES</literal> explicitly acquires
-      nontransactional or transactional table locks for the current
-      client session. Table locks can be acquired for base tables or
-      views. You must have the <literal role="priv">LOCK
-      TABLES</literal> privilege, and the
+      table locks for the current client session. Table locks can be
+      acquired for base tables or views. You must have the
+      <literal role="priv">LOCK TABLES</literal> privilege, and the
       <literal role="priv">SELECT</literal> privilege for each object to
       be locked.
     </para>

@@ -750,9 +744,8 @@
 
     <para>
       <literal role="stmt" condition="lock-tables">UNLOCK
-      TABLES</literal> explicitly releases nontransactional table locks
-      held by the current session. Transactional table locks are
-      released by ending the current transaction.
+      TABLES</literal> explicitly releases any table locks held by the
+      current session.
     </para>
 
     <para>

@@ -770,25 +763,14 @@
 
     <para>
       A table lock protects only against inappropriate reads or writes
-      by other sessions. The session holding the lock can perform
-      table-level operations such as <literal role="stmt">DROP
-      TABLE</literal>. Truncate operations are not transaction-safe, so
-      an error occurs if the session attempts one during an active
-      transaction or while holding a table lock.
+      by other sessions. The session holding the lock, even a read lock,
+      can perform table-level operations such as
+      <literal role="stmt">DROP TABLE</literal>. Truncate operations are
+      not transaction-safe, so an error occurs if the session attempts
+      one during an active transaction or while holding a table lock.
     </para>
 
     <para>
-      As of MySQL 5.4.4, <literal role="stmt">DROP TABLE</literal> is
-      allowed only if you have acquired a <literal>WRITE</literal> lock
-      with <literal role="stmt">LOCK TABLES</literal>, or if you hold no
-      locks, or if the table is a <literal>TEMPORARY</literal> table.
-      Previously, if other tables were locked, you could drop a table
-      while holding a read lock or no lock for it, which could lead to
-      deadlocks between sessions. The current stricter behavior means
-      that some usage scenarios will fail when previously they did not.
-    </para>
-
-    <para>
       The following discussion applies only to
       non-<literal>TEMPORARY</literal> tables. <literal role="stmt">LOCK
       TABLES</literal> is allowed (but ignored) for a

@@ -803,19 +785,12 @@
     </para>
 
     <para>
-      To acquire nontransactional or transactional table locks within
-      the current session, use the <literal role="stmt">LOCK
-      TABLES</literal> statement.
+      To acquire table locks within the current session, use the
+      <literal role="stmt">LOCK TABLES</literal> statement. The
+      following lock types are available:
     </para>
 
     <para>
-      <emphasis role="bold">Rules for acquisition of nontransactional
-      locks.</emphasis> MySQL supports nontransactional read and write
-      table locks. These can be acquired in nontransactional contexts
-      (that is, when autocommit is enabled).
-    </para>
-
-    <para>
       <literal>READ [LOCAL]</literal> lock:
     </para>
 

@@ -889,15 +864,21 @@
     </itemizedlist>
 
     <para>
-      A session that requires nontransactional locks must acquire all
-      the locks that it needs in a single <literal role="stmt">LOCK
-      TABLES</literal> statement. While the locks thus obtained are
-      held, the session can access only the locked tables. For example,
-      in the following sequence of statements, an error occurs for the
-      attempt to access <literal>t2</literal> because it was not locked
-      in the <literal role="stmt">LOCK TABLES</literal> statement:
+      If the <literal role="stmt">LOCK TABLES</literal> statement must
+      wait due to locks held by other sessions on any of the tables, it
+      blocks until all locks can be acquired.
     </para>
 
+    <para>
+      A session that requires locks must acquire all the locks that it
+      needs in a single <literal role="stmt">LOCK TABLES</literal>
+      statement. While the locks thus obtained are held, the session can
+      access only the locked tables. For example, in the following
+      sequence of statements, an error occurs for the attempt to access
+      <literal>t2</literal> because it was not locked in the
+      <literal role="stmt">LOCK TABLES</literal> statement:
+    </para>
+
 <programlisting>
 mysql&gt; <userinput>LOCK TABLES t1 READ;</userinput>
 mysql&gt; <userinput>SELECT COUNT(*) FROM t1;</userinput>

@@ -918,16 +899,51 @@
     </para>
 
     <para>
-      A session cannot hold nontransactional locks and use transactions
-      at the same time. Acquisition of a nontransactional lock
-      implicitly commits any active transaction for the current session,
-      and beginning a transaction implicitly releases all locks held by
-      the session. (Additional information about the interaction between
-      table locking and transactions is given in
-      <xref linkend="lock-tables-and-transactions"/>.)
+      You cannot refer to a locked table multiple times in a single
+      query using the same name. Use aliases instead, and obtain a
+      separate lock for the table and each alias:
     </para>
 
+<programlisting>
+mysql&gt; <userinput>LOCK TABLE t WRITE, t AS t1 READ;</userinput>
+mysql&gt; <userinput>INSERT INTO t SELECT * FROM t;</userinput>
+ERROR 1100: Table 't' was not locked with LOCK TABLES
+mysql&gt; <userinput>INSERT INTO t SELECT * FROM t AS t1;</userinput>
+</programlisting>
+
     <para>
+      The error occurs for the first
+      <literal role="stmt">INSERT</literal> because there are two
+      references to the same name for a locked table. The second
+      <literal role="stmt">INSERT</literal> succeeds because the
+      references to the table use different names.
+    </para>
+
+    <para>
+      If your statements refer to a table by means of an alias, you must
+      lock the table using that same alias. It does not work to lock the
+      table without specifying the alias:
+    </para>
+
+<programlisting>
+mysql&gt; <userinput>LOCK TABLE t READ;</userinput>
+mysql&gt; <userinput>SELECT * FROM t AS myalias;</userinput>
+ERROR 1100: Table 'myalias' was not locked with LOCK TABLES
+</programlisting>
+
+    <para>
+      Conversely, if you lock a table using an alias, you must refer to
+      it in your statements using that alias:
+    </para>
+
+<programlisting>
+mysql&gt; <userinput>LOCK TABLE t AS myalias READ;</userinput>
+mysql&gt; <userinput>SELECT * FROM t;</userinput>
+ERROR 1100: Table 't' was not locked with LOCK TABLES
+mysql&gt; <userinput>SELECT * FROM t AS myalias;</userinput>
+</programlisting>
+
+    <para>
       The difference between <literal>READ</literal> and <literal>READ
       LOCAL</literal> is that <literal>READ LOCAL</literal> allows
       nonconflicting <literal role="stmt">INSERT</literal> statements

@@ -961,8 +977,8 @@
     </para>
 
     <para>
-      For nontransactional locks, <literal role="stmt">LOCK
-      TABLES</literal> acquires locks as follows:
+      <literal role="stmt">LOCK TABLES</literal> acquires locks as
+      follows:
     </para>
 
     <orderedlist>

@@ -1004,257 +1020,6 @@
     </para>
 
     <para>
-      <emphasis role="bold">Rules for acquisition of transactional
-      locks.</emphasis> As of MySQL 5.4.4, MySQL supports transactional
-      shared and exclusive table locks that do not commit transactions
-      automatically. These locks apply only for transactional storage
-      engines that support them and only during a transaction (that is,
-      when autocommit is disabled).
-    </para>
-
-    <para>
-      Currently, only <literal>InnoDB</literal> supports transactional
-      locks. For other transactional storage engines or for
-      nontransactional storage engines, requests for transactional locks
-      are converted to requests for nontransactional locks, as described
-      later.
-    </para>
-
-    <para>
-      <literal>IN SHARE MODE [NOWAIT]</literal> lock:
-    </para>
-
-    <itemizedlist>
-
-      <listitem>
-        <para>
-          The session that holds the lock can read the table, and can
-          also write the table under some circumstances.
-        </para>
-      </listitem>
-
-      <listitem>
-        <para>
-          Multiple sessions can acquire an <literal>IN SHARE
-          MODE</literal> lock for the table at the same time.
-        </para>
-      </listitem>
-
-      <listitem>
-        <para>
-          Other sessions can read the table without explicitly acquiring
-          an <literal>IN SHARE MODE</literal> lock.
-        </para>
-      </listitem>
-
-    </itemizedlist>
-
-    <para>
-      <literal>IN EXCLUSIVE MODE [NOWAIT]</literal> lock:
-    </para>
-
-    <itemizedlist>
-
-      <listitem>
-        <para>
-          The session that holds the lock can read and write the table.
-        </para>
-      </listitem>
-
-      <listitem>
-        <para>
-          Only the session that holds the lock can access the table. No
-          other session can access it until the lock is released.
-        </para>
-      </listitem>
-
-      <listitem>
-        <para>
-          Lock requests for the table by other sessions block while the
-          <literal>IN EXCLUSIVE MODE</literal> lock is held.
-        </para>
-      </listitem>
-
-    </itemizedlist>
-
-    <para>
-      By default, <literal role="stmt">LOCK TABLES</literal> waits if
-      all requested locks cannot be acquired immediately (for example,
-      if the requests cannot be granted due to locks held by other
-      sessions). For transactional locks, the <literal>NOWAIT</literal>
-      modifier can be given. The intent of this modifier is that the
-      lock request will fail with an error if the lock cannot be
-      acquired immediately, but <literal>NOWAIT</literal> is not
-      currently implemented by any storage engine.
-    </para>
-
-    <para>
-      A session that requires transactional locks need not acquire them
-      all in a single <literal role="stmt">LOCK TABLES</literal>
-      statement. A session can acquire transactional locks sequentially
-      with multiple <literal role="stmt">LOCK TABLES</literal>
-      statements, each one adding new locks to the current set of locks.
-      It is even possible to acquire additional transactional locks on a
-      table for which the session already holds transactional locks.
-    </para>
-
-    <para>
-      A session that holds transactional locks can access nonlocked
-      tables while the locks are held.
-    </para>
-
-    <para>
-      Transactional locks are not specific to reading or writing. Both
-      operations are allowed to the holder of the lock, whether it is
-      shared or exclusive, with some restrictions:
-    </para>
-
-    <itemizedlist>
-
-      <listitem>
-        <para>
-          The holder of an <literal>IN EXCLUSIVE MODE</literal> lock has
-          exclusive access to read and write the table and no other
-          session can lock the table.
-        </para>
-      </listitem>
-
-      <listitem>
-        <para>
-          The holder of an <literal>IN SHARE MODE</literal> lock has
-          shared access to read the table. The lock holder can also
-          write the table, as long as no other session also has a shared
-          lock for the table. If a session that holds a shared lock has
-          written to the table, no other session can acquire a lock for
-          the table.
-        </para>
-      </listitem>
-
-    </itemizedlist>
-
-    <para>
-      Transactional locks do not apply if a session is not in
-      transactional context; that is, when autocommit mode is enabled
-      because the session has not used
-      <literal role="stmt" condition="commit">START
-      TRANSACTION</literal> or <literal>SET autocommit = 0</literal>. In
-      this case, the lock is released as soon as the
-      <literal role="stmt">LOCK TABLES</literal> statement ends, which
-      makes the statement almost a nonoperation. The only difference is
-      that the request blocks if it must wait for an existing lock to be
-      released, but then the new lock is immediately released.
-    </para>
-
-    <para>
-      For <literal role="stmt">LOCK TABLES</literal> statements that
-      involve a mix of nontransactional and transactional locks,
-      requests for transactional locks are converted to requests for
-      nontransactional locks. This occurs because a session can hold
-      multiple locks at a time, but cannot hold a mix of
-      nontransactional and transactional locks:
-    </para>
-
-    <itemizedlist>
-
-      <listitem>
-        <para>
-          It is permissible to hold multiple <literal>READ</literal> or
-          <literal>WRITE</literal> locks at the same time.
-        </para>
-      </listitem>
-
-      <listitem>
-        <para>
-          It is permissible to hold multiple <literal>IN SHARE
-          MODE</literal> or <literal>IN EXCLUSIVE MODE</literal> locks
-          at the same time.
-        </para>
-      </listitem>
-
-      <listitem>
-        <para>
-          It is not possible to hold a <literal>READ</literal> or
-          <literal>WRITE</literal> lock at the same time as an
-          <literal>IN SHARE MODE</literal> or <literal>IN EXCLUSIVE
-          MODE</literal> lock.
-        </para>
-      </listitem>
-
-    </itemizedlist>
-
-    <para>
-      For example, these operations are allowed because they request
-      only nontransactional locks, or only transactional locks:
-    </para>
-
-<programlisting>
-LOCK TABLES t1 READ, t2 WRITE, t3 READ;
-LOCK TABLES t4 IN SHARE MODE, t5 IN EXCLUSIVE MODE, t6 IN SHARE MODE;
-</programlisting>
-
-    <para>
-      But these operations cannot be processed as requested because they
-      attempt to acquire a mix of nontransactional and transactional
-      locks:
-    </para>
-
-<programlisting>
-LOCK TABLES t1 READ, t2 IN SHARE MODE;
-LOCK TABLES t3 WRITE, t4 IN EXCLUSIVE MODE;
-</programlisting>
-
-    <para>
-      For the latter statements, the requests for transactional locks
-      are converted to requests for nontransactional locks. Lock
-      conversions may succeed or fail, as described later.
-    </para>
-
-    <para>
-      You cannot refer to a locked table multiple times in a single
-      query using the same name. Use aliases instead, and obtain a
-      separate lock for the table and each alias:
-    </para>
-
-<programlisting>
-mysql&gt; <userinput>LOCK TABLE t WRITE, t AS t1 READ;</userinput>
-mysql&gt; <userinput>INSERT INTO t SELECT * FROM t;</userinput>
-ERROR 1100: Table 't' was not locked with LOCK TABLES
-mysql&gt; <userinput>INSERT INTO t SELECT * FROM t AS t1;</userinput>
-</programlisting>
-
-    <para>
-      The error occurs for the first
-      <literal role="stmt">INSERT</literal> because there are two
-      references to the same name for a locked table. The second
-      <literal role="stmt">INSERT</literal> succeeds because the
-      references to the table use different names.
-    </para>
-
-    <para>
-      If your statements refer to a table by means of an alias, you must
-      lock the table using that same alias. It does not work to lock the
-      table without specifying the alias:
-    </para>
-
-<programlisting>
-mysql&gt; <userinput>LOCK TABLE t READ;</userinput>
-mysql&gt; <userinput>SELECT * FROM t AS myalias;</userinput>
-ERROR 1100: Table 'myalias' was not locked with LOCK TABLES
-</programlisting>
-
-    <para>
-      Conversely, if you lock a table using an alias, you must refer to
-      it in your statements using that alias:
-    </para>
-
-<programlisting>
-mysql&gt; <userinput>LOCK TABLE t AS myalias READ;</userinput>
-mysql&gt; <userinput>SELECT * FROM t;</userinput>
-ERROR 1100: Table 't' was not locked with LOCK TABLES
-mysql&gt; <userinput>SELECT * FROM t AS myalias;</userinput>
-</programlisting>
-
-    <para>
       <emphasis role="bold">Rules for Lock Release</emphasis>
     </para>
 

@@ -1265,11 +1030,6 @@
       conditions.
     </para>
 
-    <para>
-      Rules for lock release when a session holds nontransactional
-      locks:
-    </para>
-
     <itemizedlist>
 
       <listitem>

@@ -1284,8 +1044,8 @@
         <para>
           If a session issues a <literal role="stmt">LOCK
           TABLES</literal> statement to acquire a lock while already
-          holding nontransactional locks, its existing locks are
-          released implicitly before the new locks are granted.
+          holding locks, its existing locks are released implicitly
+          before the new locks are granted.
         </para>
       </listitem>
 

@@ -1305,60 +1065,6 @@
     </itemizedlist>
 
     <para>
-      Rules for lock release when a session holds transactional locks:
-    </para>
-
-    <itemizedlist>
-
-      <listitem>
-        <para>
-          <literal role="stmt" condition="lock-tables">UNLOCK
-          TABLES</literal> does <emphasis>not</emphasis> release
-          transactional locks.
-        </para>
-      </listitem>
-
-      <listitem>
-        <para>
-          Ending a transaction explicitly, by either
-          <literal role="stmt">COMMIT</literal> or
-          <literal role="stmt" condition="commit">ROLLBACK</literal>,
-          releases existing locks.
-        </para>
-      </listitem>
-
-      <listitem>
-        <para>
-          Beginning a transaction (for example, with
-          <literal role="stmt" condition="commit">START
-          TRANSACTION</literal>) implicitly commits the current
-          transaction, which releases existing locks. (For additional
-          information about the interaction between table locking and
-          transactions, see
-          <xref linkend="lock-tables-and-transactions"/>.)
-        </para>
-      </listitem>
-
-      <listitem>
-        <para>
-          If the session issues a <literal role="stmt">LOCK
-          TABLES</literal> request for a nontransactional lock, that
-          implicitly commits the current transaction, which releases
-          existing locks.
-        </para>
-      </listitem>
-
-      <listitem>
-        <para>
-          Any other statement that causes an implicit commit releases
-          the existing locks. For a list, see
-          <xref linkend="implicit-commit"/>.
-        </para>
-      </listitem>
-
-    </itemizedlist>
-
-    <para>
       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

@@ -1384,237 +1090,6 @@
       </para>
     </note>
 
-    <para>
-      <emphasis role="bold">Rules for Transactional Lock
-      Conversion</emphasis>
-    </para>
-
-    <para>
-      Under some circumstances, a request for a transactional lock
-      cannot be granted:
-    </para>
-
-    <itemizedlist>
-
-      <listitem>
-        <para>
-          A session cannot use <literal role="stmt">LOCK
-          TABLES</literal> to simultaneously acquire transactional and
-          nontransactional locks.
-        </para>
-      </listitem>
-
-      <listitem>
-        <para>
-          A session cannot acquire transactional locks while currently
-          holding nontransactional locks.
-        </para>
-      </listitem>
-
-      <listitem>
-        <para>
-          A session cannot acquire transactional locks for storage
-          engines that do not support them:
-        </para>
-
-        <itemizedlist>
-
-          <listitem>
-            <para>
-              The table to be locked is nontransactional (for example,
-              <literal>MyISAM</literal>).
-            </para>
-          </listitem>
-
-          <listitem>
-            <para>
-              The table to be locked is transactional but the storage
-              engine does not support transactional locks. (Currently,
-              only <literal>InnoDB</literal> supports transactional
-              locks.)
-            </para>
-          </listitem>
-
-        </itemizedlist>
-      </listitem>
-
-    </itemizedlist>
-
-    <para>
-      When a transactional lock cannot be granted for the preceding
-      reasons, the request is converted to a request for a
-      nontransactional lock. The conversion is handled as follows:
-    </para>
-
-    <itemizedlist>
-
-      <listitem>
-        <para>
-          If strict SQL mode is enabled, lock conversion is prohibited
-          and an error occurs.
-        </para>
-
-<programlisting>
-mysql&gt; <userinput>SET sql_mode = 'STRICT_TRANS_TABLES,STRICT_ALL_TABLES';</userinput>
-Query OK, 0 rows affected (0.00 sec)
-
-mysql&gt; <userinput>LOCK TABLES t1 READ, t2 IN SHARE MODE;</userinput>
-ERROR 1615 (HY000): Cannot convert to non-transactional lock in
-strict mode on 't2'
-</programlisting>
-      </listitem>
-
-      <listitem>
-        <para>
-          Otherwise, conversion occurs and a warning is generated.
-        </para>
-
-<programlisting>
-mysql&gt; <userinput>SET sql_mode = '';</userinput>
-Query OK, 0 rows affected (0.00 sec)
-
-mysql&gt; <userinput>LOCK TABLES t1 READ, t2 IN SHARE MODE;</userinput>
-Query OK, 0 rows affected, 1 warning (0.00 sec)
-
-mysql&gt; <userinput>SHOW WARNINGS;</userinput>
-+---------+------+---------------------------------------------+
-| Level   | Code | Message                                     |
-+---------+------+---------------------------------------------+
-| Warning | 1614 | Converted to non-transactional lock on 't2' |
-+---------+------+---------------------------------------------+
-1 row in set (0.00 sec)
-</programlisting>
-      </listitem>
-
-      <listitem>
-        <para>
-          When conversion occurs, <literal>IN SHARE MODE</literal> is
-          converted to <literal>READ</literal> and <literal>IN EXCLUSIVE
-          MODE</literal> is converted to <literal>WRITE</literal>.
-        </para>
-      </listitem>
-
-    </itemizedlist>
-
-    <para>
-      The following notes describe what happens when a session already
-      holds one type of lock and then requests another lock:
-    </para>
-
-    <itemizedlist>
-
-      <listitem>
-        <para>
-          Session holds a nontransactional lock, and then requests a
-          nontransactional lock:
-        </para>
-
-        <orderedlist>
-
-          <listitem>
-            <para>
-              An implicit
-              <literal role="stmt" condition="lock-tables">UNLOCK
-              TABLES</literal> occurs, which releases the existing
-              nontransactional lock.
-            </para>
-          </listitem>
-
-          <listitem>
-            <para>
-              The new nontransactional lock is granted.
-            </para>
-          </listitem>
-
-        </orderedlist>
-      </listitem>
-
-      <listitem>
-        <para>
-          Session holds a nontransactional lock, and then requests a
-          transactional lock:
-        </para>
-
-        <orderedlist>
-
-          <listitem>
-            <para>
-              The request is converted to a request for a
-              nontransactional lock.
-            </para>
-          </listitem>
-
-          <listitem>
-            <para>
-              An implicit
-              <literal role="stmt" condition="lock-tables">UNLOCK
-              TABLES</literal> occurs, which releases the existing
-              nontransactional lock.
-            </para>
-          </listitem>
-
-          <listitem>
-            <para>
-              The new nontransactional lock is granted.
-            </para>
-          </listitem>
-
-        </orderedlist>
-      </listitem>
-
-      <listitem>
-        <para>
-          Session holds a transactional lock, and then requests a
-          transactional lock
-        </para>
-
-        <para>
-          The new transactional lock is granted without releasing the
-          existing transactional lock.
-        </para>
-      </listitem>
-
-      <listitem>
-        <para>
-          Session holds a transactional lock, and then requests a
-          nontransactional lock
-        </para>
-
-        <orderedlist>
-
-          <listitem>
-            <para>
-              An implicit commit occurs, which releases the existing
-              transactional lock.
-            </para>
-          </listitem>
-
-          <listitem>
-            <para>
-              The new nontransactional lock is granted.
-            </para>
-          </listitem>
-
-        </orderedlist>
-
-        <para>
-          Thus, the following sequence results in insertion of a row,
-          even though there is no explicit commit:
-        </para>
-
-<programlisting>
-DROP TABLE IF EXISTS t;
-CREATE TABLE t (i INT) ENGINE = InnoDB;
-START TRANSACTION;
-LOCK TABLE t IN EXCLUSIVE MODE;
-INSERT INTO t VALUES(1);
-LOCK TABLE t READ;
-SELECT * FROM t;
-</programlisting>
-      </listitem>
-
-    </itemizedlist>
-
     <section id="lock-tables-and-transactions">
 
       <title>Interaction of Table Locking and Transactions</title>


Thread
svn commit - mysqldoc@docsrva: r17137 - in trunk: . refman-5.4paul.dubois14 Oct