Author: paul
Date: 2007-01-22 20:36:17 +0100 (Mon, 22 Jan 2007)
New Revision: 4591
Log:
r18641@polar: paul | 2007-01-22 13:35:29 -0600
Clarifications regarding FLUSH TABLES WITH READ LOCK with respect
to table locking and implicit commit. (From Tim)
Modified:
trunk/refman-4.1/se-innodb.xml
trunk/refman-4.1/sql-syntax.xml
trunk/refman-5.0/se-innodb.xml
trunk/refman-5.0/sql-syntax.xml
trunk/refman-5.1/se-innodb.xml
trunk/refman-5.1/sql-syntax.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:18625
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:15112
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:13520
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:18641
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:15112
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:13520
Modified: trunk/refman-4.1/se-innodb.xml
===================================================================
--- trunk/refman-4.1/se-innodb.xml 2007-01-22 18:32:34 UTC (rev 4590)
+++ trunk/refman-4.1/se-innodb.xml 2007-01-22 19:36:17 UTC (rev 4591)
Changed blocks: 1, Lines Added: 5, Lines Deleted: 1; 779 bytes
@@ -4512,7 +4512,11 @@
<listitem>
<para>
<literal>UNLOCK TABLES</literal> commits a transaction only
- if any tables currently are locked.
+ if any tables currently have been locked with <literal>LOCK
+ TABLES</literal>. This does not occur for <literal>UNLOCK
+ TABLES</literal> following <literal>FLUSH TABLES WITH READ
+ LOCK</literal> because the latter statement does not acquire
+ table-level locks.
</para>
</listitem>
Modified: trunk/refman-4.1/sql-syntax.xml
===================================================================
--- trunk/refman-4.1/sql-syntax.xml 2007-01-22 18:32:34 UTC (rev 4590)
+++ trunk/refman-4.1/sql-syntax.xml 2007-01-22 19:36:17 UTC (rev 4591)
Changed blocks: 4, Lines Added: 55, Lines Deleted: 3; 3474 bytes
@@ -10172,8 +10172,11 @@
</para>
<para>
- Beginning a transaction also causes an implicit <literal>UNLOCK
- TABLES</literal> to be performed.
+ Beginning a transaction also causes table locks acquired with
+ <literal>LOCK TABLES</literal> to be released, as though you had
+ executed <literal>UNLOCK TABLES</literal>. Beginning a
+ transaction does not release a global read lock acquired with
+ <literal>FLUSH TABLES WITH READ LOCK</literal>.
</para>
<para>
@@ -10315,7 +10318,11 @@
<listitem>
<para>
<literal>UNLOCK TABLES</literal> commits a transaction only
- if any tables currently are locked.
+ if any tables currently have been locked with <literal>LOCK
+ TABLES</literal>. This does not occur for <literal>UNLOCK
+ TABLES</literal> following <literal>FLUSH TABLES WITH READ
+ LOCK</literal> because the latter statement does not acquire
+ table-level locks.
</para>
</listitem>
@@ -10566,6 +10573,16 @@
</para>
</listitem>
+ <listitem>
+ <para>
+ <literal>FLUSH TABLES WITH READ LOCK</literal> acquires a
+ global read lock and not table locks, so it is not subject
+ to the same behavior as <literal>LOCK TABLES</literal> and
+ <literal>UNLOCK TABLES</literal> with respect to table
+ locking and implicit commits. See <xref linkend="flush"/>.
+ </para>
+ </listitem>
+
</itemizedlist>
<para>
@@ -17466,6 +17483,41 @@
filesystem such as Veritas that can take snapshots in
time.
</para>
+
+ <para>
+ <literal>FLUSH TABLES WITH READ LOCK</literal> acquires a
+ global read lock and not table locks, so it is not subject
+ to the same behavior as <literal>LOCK TABLES</literal> and
+ <literal>UNLOCK TABLES</literal> with respect to table
+ locking and implicit commits:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>UNLOCK TABLES</literal> commits a transaction
+ only if any tables currently have been locked with
+ <literal>LOCK TABLES</literal>. This does not occur
+ for <literal>UNLOCK TABLES</literal> following
+ <literal>FLUSH TABLES WITH READ LOCK</literal> because
+ the latter statement does not acquire table-level
+ locks.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Beginning a transaction causes table locks acquired
+ with <literal>LOCK TABLES</literal> to be released, as
+ though you had executed <literal>UNLOCK
+ TABLES</literal>. Beginning a transaction does not
+ release a global read lock acquired with
+ <literal>FLUSH TABLES WITH READ LOCK</literal>.
+ </para>
+ </listitem>
+
+ </itemizedlist>
</listitem>
<listitem>
Modified: trunk/refman-5.0/se-innodb.xml
===================================================================
--- trunk/refman-5.0/se-innodb.xml 2007-01-22 18:32:34 UTC (rev 4590)
+++ trunk/refman-5.0/se-innodb.xml 2007-01-22 19:36:17 UTC (rev 4591)
Changed blocks: 1, Lines Added: 5, Lines Deleted: 1; 779 bytes
@@ -4515,7 +4515,11 @@
<listitem>
<para>
<literal>UNLOCK TABLES</literal> commits a transaction only
- if any tables are currently locked.
+ if any tables currently have been locked with <literal>LOCK
+ TABLES</literal>. This does not occur for <literal>UNLOCK
+ TABLES</literal> following <literal>FLUSH TABLES WITH READ
+ LOCK</literal> because the latter statement does not acquire
+ table-level locks.
</para>
</listitem>
Modified: trunk/refman-5.0/sql-syntax.xml
===================================================================
--- trunk/refman-5.0/sql-syntax.xml 2007-01-22 18:32:34 UTC (rev 4590)
+++ trunk/refman-5.0/sql-syntax.xml 2007-01-22 19:36:17 UTC (rev 4591)
Changed blocks: 4, Lines Added: 55, Lines Deleted: 3; 3474 bytes
@@ -10892,8 +10892,11 @@
</para>
<para>
- Beginning a transaction also causes an implicit <literal>UNLOCK
- TABLES</literal> to be performed.
+ Beginning a transaction also causes table locks acquired with
+ <literal>LOCK TABLES</literal> to be released, as though you had
+ executed <literal>UNLOCK TABLES</literal>. Beginning a
+ transaction does not release a global read lock acquired with
+ <literal>FLUSH TABLES WITH READ LOCK</literal>.
</para>
<para>
@@ -11032,7 +11035,11 @@
<listitem>
<para>
<literal>UNLOCK TABLES</literal> commits a transaction only
- if any tables currently are locked.
+ if any tables currently have been locked with <literal>LOCK
+ TABLES</literal>. This does not occur for <literal>UNLOCK
+ TABLES</literal> following <literal>FLUSH TABLES WITH READ
+ LOCK</literal> because the latter statement does not acquire
+ table-level locks.
</para>
</listitem>
@@ -11322,6 +11329,16 @@
</para>
</listitem>
+ <listitem>
+ <para>
+ <literal>FLUSH TABLES WITH READ LOCK</literal> acquires a
+ global read lock and not table locks, so it is not subject
+ to the same behavior as <literal>LOCK TABLES</literal> and
+ <literal>UNLOCK TABLES</literal> with respect to table
+ locking and implicit commits. See <xref linkend="flush"/>.
+ </para>
+ </listitem>
+
</itemizedlist>
<para>
@@ -19934,6 +19951,41 @@
filesystem such as Veritas that can take snapshots in
time.
</para>
+
+ <para>
+ <literal>FLUSH TABLES WITH READ LOCK</literal> acquires a
+ global read lock and not table locks, so it is not subject
+ to the same behavior as <literal>LOCK TABLES</literal> and
+ <literal>UNLOCK TABLES</literal> with respect to table
+ locking and implicit commits:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>UNLOCK TABLES</literal> commits a transaction
+ only if any tables currently have been locked with
+ <literal>LOCK TABLES</literal>. This does not occur
+ for <literal>UNLOCK TABLES</literal> following
+ <literal>FLUSH TABLES WITH READ LOCK</literal> because
+ the latter statement does not acquire table-level
+ locks.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Beginning a transaction causes table locks acquired
+ with <literal>LOCK TABLES</literal> to be released, as
+ though you had executed <literal>UNLOCK
+ TABLES</literal>. Beginning a transaction does not
+ release a global read lock acquired with
+ <literal>FLUSH TABLES WITH READ LOCK</literal>.
+ </para>
+ </listitem>
+
+ </itemizedlist>
</listitem>
<listitem>
Modified: trunk/refman-5.1/se-innodb.xml
===================================================================
--- trunk/refman-5.1/se-innodb.xml 2007-01-22 18:32:34 UTC (rev 4590)
+++ trunk/refman-5.1/se-innodb.xml 2007-01-22 19:36:17 UTC (rev 4591)
Changed blocks: 1, Lines Added: 5, Lines Deleted: 1; 779 bytes
@@ -4466,7 +4466,11 @@
<listitem>
<para>
<literal>UNLOCK TABLES</literal> commits a transaction only
- if any tables are currently locked.
+ if any tables currently have been locked with <literal>LOCK
+ TABLES</literal>. This does not occur for <literal>UNLOCK
+ TABLES</literal> following <literal>FLUSH TABLES WITH READ
+ LOCK</literal> because the latter statement does not acquire
+ table-level locks.
</para>
</listitem>
Modified: trunk/refman-5.1/sql-syntax.xml
===================================================================
--- trunk/refman-5.1/sql-syntax.xml 2007-01-22 18:32:34 UTC (rev 4590)
+++ trunk/refman-5.1/sql-syntax.xml 2007-01-22 19:36:17 UTC (rev 4591)
Changed blocks: 4, Lines Added: 55, Lines Deleted: 3; 3474 bytes
@@ -12233,8 +12233,11 @@
</para>
<para>
- Beginning a transaction also causes an implicit <literal>UNLOCK
- TABLES</literal> to be performed.
+ Beginning a transaction also causes table locks acquired with
+ <literal>LOCK TABLES</literal> to be released, as though you had
+ executed <literal>UNLOCK TABLES</literal>. Beginning a
+ transaction does not release a global read lock acquired with
+ <literal>FLUSH TABLES WITH READ LOCK</literal>.
</para>
<para>
@@ -12372,7 +12375,11 @@
<listitem>
<para>
<literal>UNLOCK TABLES</literal> commits a transaction only
- if any tables currently are locked.
+ if any tables currently have been locked with <literal>LOCK
+ TABLES</literal>. This does not occur for <literal>UNLOCK
+ TABLES</literal> following <literal>FLUSH TABLES WITH READ
+ LOCK</literal> because the latter statement does not acquire
+ table-level locks.
</para>
</listitem>
@@ -12647,6 +12654,16 @@
</para>
</listitem>
+ <listitem>
+ <para>
+ <literal>FLUSH TABLES WITH READ LOCK</literal> acquires a
+ global read lock and not table locks, so it is not subject
+ to the same behavior as <literal>LOCK TABLES</literal> and
+ <literal>UNLOCK TABLES</literal> with respect to table
+ locking and implicit commits. See <xref linkend="flush"/>.
+ </para>
+ </listitem>
+
</itemizedlist>
<para>
@@ -21517,6 +21534,41 @@
filesystem such as Veritas that can take snapshots in
time.
</para>
+
+ <para>
+ <literal>FLUSH TABLES WITH READ LOCK</literal> acquires a
+ global read lock and not table locks, so it is not subject
+ to the same behavior as <literal>LOCK TABLES</literal> and
+ <literal>UNLOCK TABLES</literal> with respect to table
+ locking and implicit commits:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>UNLOCK TABLES</literal> commits a transaction
+ only if any tables currently have been locked with
+ <literal>LOCK TABLES</literal>. This does not occur
+ for <literal>UNLOCK TABLES</literal> following
+ <literal>FLUSH TABLES WITH READ LOCK</literal> because
+ the latter statement does not acquire table-level
+ locks.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Beginning a transaction causes table locks acquired
+ with <literal>LOCK TABLES</literal> to be released, as
+ though you had executed <literal>UNLOCK
+ TABLES</literal>. Beginning a transaction does not
+ release a global read lock acquired with
+ <literal>FLUSH TABLES WITH READ LOCK</literal>.
+ </para>
+ </listitem>
+
+ </itemizedlist>
</listitem>
<listitem>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r4591 - in trunk: . refman-4.1 refman-5.0 refman-5.1 | paul | 22 Jan |
