Author: paul
Date: 2008-06-10 21:10:32 +0200 (Tue, 10 Jun 2008)
New Revision: 10925
Log:
r31927@frost: paul | 2008-06-10 14:11:08 -0500
Minor LOCK TABLES updates
Modified:
trunk/it/refman-5.1/sql-syntax.xml
trunk/pt/refman-5.1/sql-syntax.xml
trunk/refman-4.1/sql-syntax.xml
trunk/refman-5.0/sql-syntax.xml
trunk/refman-5.1/sql-syntax.xml
trunk/refman-6.0/lock-tables-tmp.xml
trunk/refman-6.0/sql-syntax.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:35828
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:31925
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:31613
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:35828
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:31927
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:31613
Modified: trunk/it/refman-5.1/sql-syntax.xml
===================================================================
--- trunk/it/refman-5.1/sql-syntax.xml 2008-06-10 17:04:04 UTC (rev 10924)
+++ trunk/it/refman-5.1/sql-syntax.xml 2008-06-10 19:10:32 UTC (rev 10925)
Changed blocks: 2, Lines Added: 4, Lines Deleted: 2; 1082 bytes
@@ -15049,7 +15049,9 @@
by the statement. Because <literal>LOCK TABLES</literal> will
not lock views, if the operation that you are performing uses
any views, you must also lock all base tables on which those
- views depend.
+ views depend. (An exception is that you need not lock
+ <literal>TEMPORARY</literal> tables, and you can access them
+ even while holding locks for other tables.)
</para>
<para>
@@ -15137,7 +15139,7 @@
tables in transactional mode (autocommit = 0), a waiting
<literal>LOW_PRIORITY WRITE</literal> lock acts like a regular
<literal>WRITE</literal> lock and causes subsequent
- <literal>READ</literal> lock requests to wait.)
+ <literal>READ</literal> lock requests to wait.
</para>
<para>
Modified: trunk/pt/refman-5.1/sql-syntax.xml
===================================================================
--- trunk/pt/refman-5.1/sql-syntax.xml 2008-06-10 17:04:04 UTC (rev 10924)
+++ trunk/pt/refman-5.1/sql-syntax.xml 2008-06-10 19:10:32 UTC (rev 10925)
Changed blocks: 2, Lines Added: 4, Lines Deleted: 2; 1082 bytes
@@ -15049,7 +15049,9 @@
by the statement. Because <literal>LOCK TABLES</literal> will
not lock views, if the operation that you are performing uses
any views, you must also lock all base tables on which those
- views depend.
+ views depend. (An exception is that you need not lock
+ <literal>TEMPORARY</literal> tables, and you can access them
+ even while holding locks for other tables.)
</para>
<para>
@@ -15137,7 +15139,7 @@
tables in transactional mode (autocommit = 0), a waiting
<literal>LOW_PRIORITY WRITE</literal> lock acts like a regular
<literal>WRITE</literal> lock and causes subsequent
- <literal>READ</literal> lock requests to wait.)
+ <literal>READ</literal> lock requests to wait.
</para>
<para>
Modified: trunk/refman-4.1/sql-syntax.xml
===================================================================
--- trunk/refman-4.1/sql-syntax.xml 2008-06-10 17:04:04 UTC (rev 10924)
+++ trunk/refman-4.1/sql-syntax.xml 2008-06-10 19:10:32 UTC (rev 10925)
Changed blocks: 2, Lines Added: 4, Lines Deleted: 2; 1087 bytes
@@ -11569,7 +11569,9 @@
tables that you are going to use in your statements. While the
locks obtained with a <literal>LOCK TABLES</literal> statement
are in effect, you cannot access any tables that were not locked
- by the statement.
+ by the statement. (An exception is that you need not lock
+ <literal>TEMPORARY</literal> tables, and you can access them
+ even while holding locks for other tables.)
</para>
<para>
@@ -11662,7 +11664,7 @@
tables in transactional mode (autocommit = 0), a waiting
<literal>LOW_PRIORITY WRITE</literal> lock acts like a regular
<literal>WRITE</literal> lock and causes subsequent
- <literal>READ</literal> lock requests to wait.)
+ <literal>READ</literal> lock requests to wait.
</para>
<para>
Modified: trunk/refman-5.0/sql-syntax.xml
===================================================================
--- trunk/refman-5.0/sql-syntax.xml 2008-06-10 17:04:04 UTC (rev 10924)
+++ trunk/refman-5.0/sql-syntax.xml 2008-06-10 19:10:32 UTC (rev 10925)
Changed blocks: 2, Lines Added: 4, Lines Deleted: 2; 1073 bytes
@@ -12472,7 +12472,9 @@
by the statement. Because <literal>LOCK TABLES</literal> will
not lock views, if the operation that you are performing uses
any views, you must also lock all base tables on which those
- views depend.
+ views depend. (An exception is that you need not lock
+ <literal>TEMPORARY</literal> tables, and you can access them
+ even while holding locks for other tables.)
</para>
<para>
@@ -12565,7 +12567,7 @@
tables in transactional mode (autocommit = 0), a waiting
<literal>LOW_PRIORITY WRITE</literal> lock acts like a regular
<literal>WRITE</literal> lock and causes subsequent
- <literal>READ</literal> lock requests to wait.)
+ <literal>READ</literal> lock requests to wait.
</para>
<para>
Modified: trunk/refman-5.1/sql-syntax.xml
===================================================================
--- trunk/refman-5.1/sql-syntax.xml 2008-06-10 17:04:04 UTC (rev 10924)
+++ trunk/refman-5.1/sql-syntax.xml 2008-06-10 19:10:32 UTC (rev 10925)
Changed blocks: 2, Lines Added: 4, Lines Deleted: 2; 1073 bytes
@@ -15049,7 +15049,9 @@
by the statement. Because <literal>LOCK TABLES</literal> will
not lock views, if the operation that you are performing uses
any views, you must also lock all base tables on which those
- views depend.
+ views depend. (An exception is that you need not lock
+ <literal>TEMPORARY</literal> tables, and you can access them
+ even while holding locks for other tables.)
</para>
<para>
@@ -15137,7 +15139,7 @@
tables in transactional mode (autocommit = 0), a waiting
<literal>LOW_PRIORITY WRITE</literal> lock acts like a regular
<literal>WRITE</literal> lock and causes subsequent
- <literal>READ</literal> lock requests to wait.)
+ <literal>READ</literal> lock requests to wait.
</para>
<para>
Modified: trunk/refman-6.0/lock-tables-tmp.xml
===================================================================
--- trunk/refman-6.0/lock-tables-tmp.xml 2008-06-10 17:04:04 UTC (rev 10924)
+++ trunk/refman-6.0/lock-tables-tmp.xml 2008-06-10 19:10:32 UTC (rev 10925)
Changed blocks: 9, Lines Added: 104, Lines Deleted: 75; 10049 bytes
@@ -40,37 +40,42 @@
</programlisting>
<para>
- [ TODO: Discuss name locks in optimizer chapter? It's not true that
+ [TODO: Discuss name locks in optimizer chapter? It's not true that
you cannot access any non-locked table while you hold locks: You can
access TEMPORARY tables. LOCK TABLES appears to lock TEMPORARY
- tables, but should you even bother, given the preceding sentence?
- How do transactional lock requests and requests to enable read_only
- interact? ]
+ tables, but there is no need: Only the thread that created the table
+ can access it.
</para>
<remark role="help-description-begin"/>
<para>
- <literal>LOCK TABLES</literal> acquires table locks for the current
- thread. It locks base tables but not views. To use <literal>LOCK
- TABLES</literal>, you must have the <literal>LOCK TABLES</literal>
- privilege, and the <literal>SELECT</literal> privilege for each
- table to be locked.
+ <literal>LOCK TABLES</literal> explicity acquires table locks for
+ the current thread. This applies both to non-transactional and
+ transactional locks. It locks base tables but not views. To use
+ <literal>LOCK TABLES</literal>, you must have the <literal>LOCK
+ TABLES</literal> privilege, and the <literal>SELECT</literal>
+ privilege for each table to be locked.
</para>
<para>
- <literal>UNLOCK TABLES</literal> explicitly releases any table locks
- [UPDATE: only non-transactional locks now] held by the current
- thread. Another use for <literal>UNLOCK TABLES</literal> is to
- release the global read lock acquired with <literal>FLUSH TABLES
- WITH READ LOCK</literal>. (You can lock all tables in all databases
- with a read lock with the <literal>FLUSH TABLES WITH READ
- LOCK</literal> statement. See <xref linkend="flush"/>. This is a
- very convenient way to get backups if you have a filesystem such as
- Veritas that can take snapshots in time.)
+ <literal>UNLOCK TABLES</literal> explicitly releases
+ non-transactional table locks held by the current thread.
+ Transactional table locks are released when the current transaction
+ ends.
</para>
<para>
+ Another use for <literal>UNLOCK TABLES</literal> is to release the
+ global read lock acquired with <literal>FLUSH TABLES WITH READ
+ LOCK</literal>. (You can lock all tables in all databases with a
+ read lock with the <literal>FLUSH TABLES WITH READ LOCK</literal>
+ statement. See <xref linkend="flush"/>. This is a very convenient
+ way to get backups if you have a filesystem such as Veritas that can
+ take snapshots in time.)
+ </para>
+
+ <para>
MySQL supports non-transactional locks:
</para>
@@ -95,10 +100,6 @@
affects lock scheduling if the <literal>WRITE</literal> lock
request must wait.
</para>
-
- <para>
- [Can the holder of a WRITE lock also READ from the table? TEST]
- </para>
</listitem>
</itemizedlist>
@@ -139,9 +140,10 @@
</itemizedlist>
<para>
- For transactional locks, the <literal>NOWAIT</literal> modifier
- causes the request to fail with an error if the lock cannot be
- acquired immediately.
+ 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.
+ However, <literal>NOWAIT</literal> is not currently implemented.
</para>
<para>
@@ -170,10 +172,14 @@
<para>
By default, if the <literal>LOCK TABLES</literal> statement must
wait due to locks held by other threads on any of the tables, it
- blocks until all locks can be acquired. If a waited-for lock was
- requested with the <literal>NOWAIT</literal> option and the lock
- cannot be acquired immediately, <literal>LOCK TABLES</literal>
- fails with an error.
+ blocks until all locks can be acquired.
+
+ <remark role="todo">
+ [Uncomment when NOWAIT is implemented] If a waited-for lock
+ was requested with the <literal>NOWAIT</literal> option and
+ the lock cannot be acquired immediately, <literal>LOCK
+ TABLES</literal> fails with an error.
+ </remark>
</para>
</listitem>
@@ -291,7 +297,10 @@
effect, you cannot access any tables that were not locked by the
statement. Because <literal>LOCK TABLES</literal> will not lock
views, if the operation that you are performing uses any views, you
- must also lock all base tables on which those views depend.
+ must also lock all base tables on which those views depend. (An
+ exception is that you need not lock <literal>TEMPORARY</literal>
+ tables, and you can access them even while holding locks for other
+ tables.)
</para>
<para>
@@ -392,13 +401,17 @@
in transactional mode (autocommit = 0), a waiting
<literal>LOW_PRIORITY WRITE</literal> lock acts like a regular
<literal>WRITE</literal> lock and causes subsequent
- <literal>READ</literal> lock requests to wait.)
+ <literal>READ</literal> lock requests to wait.
</para>
<para>
<literal>LOCK TABLES</literal> works as follows:
</para>
+ <para>
+ [TODO: Does this apply to transactional locks?]
+ </para>
+
<orderedlist>
<listitem>
@@ -438,6 +451,65 @@
</para>
<para>
+ <emphasis role="bold"><literal>IN SHARE MODE</literal> and
+ <literal>IN EXCLUSIVE MODE</literal> Lock Semantics</emphasis>
+ </para>
+
+ <para>
+ The <literal>IN SHARE MODE</literal> and <literal>IN EXCLUSIVE
+ MODE</literal> lock types support transactional table locks that do
+ not commit transactions automatically. Multiple clients can acquire
+ a shared lock simultaneously. Only one client at a time can acquire
+ an exclusive lock.
+ </para>
+
+ <para>
+ Following <literal>LOCK TABLES ... IN SHARE MODE</literal> or
+ <literal>LOCK TABLES ... IN EXCLUSIVE MODE</literal>, you can access
+ tables not mentioned in the <literal>LOCK TABLES</literal>
+ statement. You can also issue <literal>LOCK TABLES</literal>
+ statements that acquire transactional locks many times in
+ succession, adding additional tables to the locked set, and without
+ unlocking any tables that were locked previously. When using
+ <literal>LOCK TABLES</literal> with <literal>IN SHARE MODE</literal>
+ or <literal>IN EXCLUSIVE MODE</literal>, tables are not unlocked
+ until the transaction ends.
+ </para>
+
+ <para>
+ Transactional locks acquired with <literal>LOCK TABLES</literal> are
+ released when the transaction ends, either explicitly with
+ <literal>COMMIT</literal> or <literal>ROLLBACK</literal>, or
+ implicitly due to a statement that causes implicit commit or because
+ the connection ends. <xref linkend="implicit-commit"/>, lists those
+ statements that cause implicit commit.
+ </para>
+
+ <para>
+ By default, <literal>LOCK TABLES</literal> waits for transactional
+ locks if they cannot be acquired immediately.
+
+ <remark role="todo">
+ [Uncomment when NOWAIT is implemented] The
+ <literal>NOWAIT</literal> option causes the statement to return an
+ error instead if a wait would be necessary.
+ </remark>
+ </para>
+
+ <para>
+ The behavior of <literal>LOCK TABLES</literal> remains unchanged for
+ <literal>READ</literal> or <literal>WRITE</literal> locks (that is,
+ when not using <literal>IN SHARE MODE</literal> or <literal>IN
+ EXCLUSIVE MODE</literal>).
+ </para>
+
+ <para>
+ <emphasis role="bold">Interaction of Non-Transactional Locks and
+ Transactions</emphasis>
+ </para>
+
+ <para>
+ When used for acquiring and releasing non-transactional locks,
<literal>LOCK TABLES</literal> and <literal>UNLOCK TABLES</literal>
interact with the use of transactional tables as follows:
</para>
@@ -463,7 +535,7 @@
</para>
<para>
- [Does it release xact locks?]
+ [Locked with *non-xact* locks? Does it release xact locks?]
</para>
</listitem>
@@ -510,49 +582,6 @@
</itemizedlist>
<para>
- <emphasis role="bold"><literal>IN SHARE MODE</literal> and
- <literal>IN EXCLUSIVE MODE</literal> Lock Semantics</emphasis>
- </para>
-
- <para>
- The <literal>IN SHARE MODE</literal> and <literal>IN EXCLUSIVE
- MODE</literal> lock types support transactional table locks that do
- not commit transactions automatically. Multiple clients can acquire
- a shared lock simultaneously. Only one client at a time can acquire
- an exclusive lock.
- </para>
-
- <para>
- Following <literal>LOCK TABLES ... IN SHARE MODE</literal> or
- <literal>LOCK TABLES ... IN EXCLUSIVE MODE</literal>, you can access
- tables not mentioned in the <literal>LOCK TABLES</literal>
- statement. You can also issue <literal>LOCK TABLES</literal>
- statements that acquire transactional locks many times in
- succession, adding additional tables to the locked set, and without
- unlocking any tables that were locked previously. When using
- <literal>LOCK TABLES</literal> with <literal>IN SHARE MODE</literal>
- or <literal>IN EXCLUSIVE MODE</literal>, tables are not unlocked
- until the transaction ends.
- </para>
-
- <para>
- [UNLOCK TABLES does not release those locks?]
- </para>
-
- <para>
- By default, <literal>LOCK TABLES</literal> waits for transactional
- locks if they cannot be acquired immediately. The
- <literal>NOWAIT</literal> option causes the statement to return an
- error instead if a wait would be necessary.
- </para>
-
- <para>
- The behavior of <literal>LOCK TABLES</literal> when not using
- <literal>IN SHARE MODE</literal> or <literal>IN EXCLUSIVE
- MODE</literal> remains unchanged.
- </para>
-
- <para>
<emphasis role="bold">Other Table-Locking Notes</emphasis>
</para>
Modified: trunk/refman-6.0/sql-syntax.xml
===================================================================
--- trunk/refman-6.0/sql-syntax.xml 2008-06-10 17:04:04 UTC (rev 10924)
+++ trunk/refman-6.0/sql-syntax.xml 2008-06-10 19:10:32 UTC (rev 10925)
Changed blocks: 3, Lines Added: 24, Lines Deleted: 8; 2620 bytes
@@ -15530,7 +15530,9 @@
by the statement. Because <literal>LOCK TABLES</literal> will
not lock views, if the operation that you are performing uses
any views, you must also lock all base tables on which those
- views depend.
+ views depend. (An exception is that you need not lock
+ <literal>TEMPORARY</literal> tables, and you can access them
+ even while holding locks for other tables.)
</para>
<para>
@@ -15623,7 +15625,7 @@
tables in transactional mode (autocommit = 0), a waiting
<literal>LOW_PRIORITY WRITE</literal> lock acts like a regular
<literal>WRITE</literal> lock and causes subsequent
- <literal>READ</literal> lock requests to wait.)
+ <literal>READ</literal> lock requests to wait.
</para>
<para>
@@ -15767,16 +15769,30 @@
</para>
<para>
+ Transactional locks acquired with <literal>LOCK TABLES</literal>
+ are released when the transaction ends, either explicitly with
+ <literal>COMMIT</literal> or <literal>ROLLBACK</literal>, or
+ implicitly due to a statement that causes implicit commit or
+ because the connection ends. <xref linkend="implicit-commit"/>,
+ lists those statements that cause implicit commit.
+ </para>
+
+ <para>
By default, <literal>LOCK TABLES</literal> waits for
- transactional locks if they cannot be acquired immediately. The
- <literal>NOWAIT</literal> option causes the statement to return
- an error instead if a wait would be necessary.
+ transactional locks if they cannot be acquired immediately.
+
+ <remark role="todo">
+ [Uncomment when NOWAIT is implemented] The
+ <literal>NOWAIT</literal> option causes the statement to
+ return an error instead if a wait would be necessary.
+ </remark>
</para>
<para>
- The behavior of <literal>LOCK TABLES</literal> when not using
- <literal>IN SHARE MODE</literal> or <literal>IN EXCLUSIVE
- MODE</literal> remains unchanged.
+ The behavior of <literal>LOCK TABLES</literal> remains unchanged
+ for <literal>READ</literal> or <literal>WRITE</literal> locks
+ (that is, when not using <literal>IN SHARE MODE</literal> or
+ <literal>IN EXCLUSIVE MODE</literal>).
</para>
<para>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r10925 - in trunk: . it/refman-5.1 pt/refman-5.1 refman-4.1 refman-5.0 refman-5.1 refman-6.0 | paul | 10 Jun |
