Author: paul
Date: 2008-06-13 21:40:57 +0200 (Fri, 13 Jun 2008)
New Revision: 10953
Log:
r31698@arctic: paul | 2008-06-13 14:41:36 -0500
LOCK TABLE revisions.
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:31988
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:31696
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:35828
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:31988
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:31698
Modified: trunk/it/refman-5.1/sql-syntax.xml
===================================================================
--- trunk/it/refman-5.1/sql-syntax.xml 2008-06-13 19:27:24 UTC (rev 10952)
+++ trunk/it/refman-5.1/sql-syntax.xml 2008-06-13 19:40:57 UTC (rev 10953)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 738 bytes
@@ -15118,7 +15118,7 @@
that thread (and all other threads) can only read from the
table. If a thread obtains a <literal>WRITE</literal> lock on a
table, only the thread holding the lock can write to the table
- (that thread can also read from the table). Other threads are
+ (that thread can also read from the table); other threads are
blocked from reading or writing the table until the lock has
been released.
</para>
Modified: trunk/pt/refman-5.1/sql-syntax.xml
===================================================================
--- trunk/pt/refman-5.1/sql-syntax.xml 2008-06-13 19:27:24 UTC (rev 10952)
+++ trunk/pt/refman-5.1/sql-syntax.xml 2008-06-13 19:40:57 UTC (rev 10953)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 738 bytes
@@ -15118,7 +15118,7 @@
that thread (and all other threads) can only read from the
table. If a thread obtains a <literal>WRITE</literal> lock on a
table, only the thread holding the lock can write to the table
- (that thread can also read from the table). Other threads are
+ (that thread can also read from the table); other threads are
blocked from reading or writing the table until the lock has
been released.
</para>
Modified: trunk/refman-4.1/sql-syntax.xml
===================================================================
--- trunk/refman-4.1/sql-syntax.xml 2008-06-13 19:27:24 UTC (rev 10952)
+++ trunk/refman-4.1/sql-syntax.xml 2008-06-13 19:40:57 UTC (rev 10953)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 729 bytes
@@ -11637,7 +11637,7 @@
that thread (and all other threads) can only read from the
table. If a thread obtains a <literal>WRITE</literal> lock on a
table, only the thread holding the lock can write to the table
- (that thread can also read from the table). Other threads are
+ (that thread can also read from the table); other threads are
blocked from reading or writing the table until the lock has
been released.
</para>
Modified: trunk/refman-5.0/sql-syntax.xml
===================================================================
--- trunk/refman-5.0/sql-syntax.xml 2008-06-13 19:27:24 UTC (rev 10952)
+++ trunk/refman-5.0/sql-syntax.xml 2008-06-13 19:40:57 UTC (rev 10953)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 729 bytes
@@ -12540,7 +12540,7 @@
that thread (and all other threads) can only read from the
table. If a thread obtains a <literal>WRITE</literal> lock on a
table, only the thread holding the lock can write to the table
- (that thread can also read from the table). Other threads are
+ (that thread can also read from the table); other threads are
blocked from reading or writing the table until the lock has
been released.
</para>
Modified: trunk/refman-5.1/sql-syntax.xml
===================================================================
--- trunk/refman-5.1/sql-syntax.xml 2008-06-13 19:27:24 UTC (rev 10952)
+++ trunk/refman-5.1/sql-syntax.xml 2008-06-13 19:40:57 UTC (rev 10953)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 729 bytes
@@ -15118,7 +15118,7 @@
that thread (and all other threads) can only read from the
table. If a thread obtains a <literal>WRITE</literal> lock on a
table, only the thread holding the lock can write to the table
- (that thread can also read from the table). Other threads are
+ (that thread can also read from the table); other threads are
blocked from reading or writing the table until the lock has
been released.
</para>
Modified: trunk/refman-6.0/lock-tables-tmp.xml
===================================================================
--- trunk/refman-6.0/lock-tables-tmp.xml 2008-06-13 19:27:24 UTC (rev 10952)
+++ trunk/refman-6.0/lock-tables-tmp.xml 2008-06-13 19:40:57 UTC (rev 10953)
Changed blocks: 20, Lines Added: 66, Lines Deleted: 70; 13475 bytes
@@ -47,12 +47,12 @@
<remark role="help-description-begin"/>
<para>
- <literal>LOCK TABLES</literal> explicitly acquires table locks for
- the current client session. 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.
+ <literal>LOCK TABLES</literal> explicitly acquires non-transactional
+ or transactional table locks for the current client session. 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>
@@ -95,25 +95,16 @@
read the table. Only one session at a time can acquire a
<literal>WRITE</literal> lock for a table. The
<literal>LOW_PRIORITY</literal> modifier affects lock scheduling
- if the <literal>WRITE</literal> lock request must wait.
+ if the <literal>WRITE</literal> lock request must wait, as
+ described later.
</para>
</listitem>
</itemizedlist>
<para>
- A session cannot use non-transactional locks and transactions at the
- same time. Acquisition of a non-transactional lock implicitly
- commits any active transaction for the current session, and
- beginning a transaction implicitly releases any non-transactional
- locks held by the session. (Additional information about the
- interaction between table locking and transactions is given later in
- this section.)
- </para>
-
- <para>
As of MySQL 6.0.3, MySQL also supports transactional locks that can
- be used in conjunction with transactions:
+ be used within transactions:
</para>
<itemizedlist>
@@ -121,15 +112,15 @@
<listitem>
<para>
<literal>IN SHARE MODE [NOWAIT]</literal>: Locks a table for
- shared access. Multiple clients can acquire an <literal>IN SHARE
- MODE</literal> lock for a table simultaneously.
+ shared access. Multiple sessions can acquire an <literal>IN
+ SHARE MODE</literal> lock for a table simultaneously.
</para>
</listitem>
<listitem>
<para>
<literal>IN EXCLUSIVE MODE [NOWAIT]</literal>: Locks a table for
- exclusive access (typically for writing). Only one client at a
+ exclusive access (typically for writing). Only one session at a
time can acquire an <literal>IN EXCLUSIVE MODE</literal> lock
for a table.
</para>
@@ -146,13 +137,13 @@
<para>
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.
+ fail with an error if the lock cannot be acquired immediately, but
+ <literal>NOWAIT</literal> is not currently implemented.
</para>
<para>
- Transactional locks can be acquired only while autocommit
- is disabled. If autocommit is enabled, requests are converted to
+ Transactional locks can be acquired only while autocommit is
+ disabled. If autocommit is enabled, requests are converted to
READ/WRITE requests, or an error occurs if strict SQL mode is
enabled (strict mode prevents request conversion). [If conversion
occurs, is NOWAIT ignored if present, given that it doesn't apply to
@@ -160,8 +151,18 @@
</para>
<para>
+ A session cannot hold non-transactional locks and transactions at
+ the same time. Acquisition of a non-transactional lock implicitly
+ commits any active transaction for the current session, and
+ beginning a transaction implicitly releases any non-transactional
+ locks held by the session. (Additional information about the
+ interaction between table locking and transactions is given later in
+ this section.)
+ </para>
+
+ <para>
The following general rules apply to acquisition and release of
- locks by a given thread:
+ locks by a given session:
</para>
<itemizedlist>
@@ -174,9 +175,9 @@
<listitem>
<para>
- 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 the <literal>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.
<remark role="todo">
[Uncomment when NOWAIT is implemented] If a waited-for lock
@@ -208,7 +209,7 @@
<listitem>
<para>
<literal>LOCK TABLES</literal> releases any table locks
- currently held by the thread before acquiring new locks.
+ currently held by the session before acquiring new locks.
</para>
<para>
@@ -246,7 +247,8 @@
<listitem>
<para>
- One thread cannot release locks held by another thread.
+ One session cannot acquire locks for another session or release
+ locks held by another session.
</para>
</listitem>
@@ -267,10 +269,10 @@
<para>
A table lock protects only against inappropriate reads or writes by
- other clients. The client holding the lock can perform table-level
+ other sessions. The session holding the lock can perform table-level
operations such as <literal>DROP TABLE</literal>. Truncate
operations are not transaction-safe, so an error occurs if the
- client attempts one during an active transaction or while holding a
+ session attempts one during an active transaction or while holding a
table lock.
</para>
@@ -280,21 +282,14 @@
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 clients. The new
- stricter behavior means that some usage scenarios will fail when
- previously they did not.)
+ 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>
<remark role="help-description-end"/>
<para>
- [ You can lock multiple tables at the same time. You can lock a
- table multiple times, as long as you refer to it by a different name
- for each lock. Each locked name can be referred to a single time in
- a statement.
- </para>
-
- <para>
When you use <literal>LOCK TABLES</literal>, you must lock all
tables that you are going to use in your statements. While the locks
obtained with a <literal>LOCK TABLES</literal> statement are in
@@ -357,17 +352,17 @@
</para>
<para>
- [If one thread holds a READ lock, any other thread can read from the
- table, whether or not it also holds a READ lock?]
+ [If one session holds a READ lock, any other session can read from
+ the table, whether or not it also holds a READ lock?]
</para>
<para>
- If a thread obtains a <literal>READ</literal> lock on a table, that
- thread (and all other threads) can only read from the table. If a
- thread obtains a <literal>WRITE</literal> lock on a table, only the
- thread holding the lock can write to the table. Other threads are
- blocked from reading or writing the table until the lock has been
- released.
+ If a session obtains a <literal>READ</literal> lock on a table, that
+ session (and all other sessions) can only read from the table. If a
+ session obtains a <literal>WRITE</literal> lock on a table, only the
+ session holding the lock can write to the table (that session can
+ also read from the table); other sessions are blocked from reading
+ or writing the table until the lock has been released.
</para>
<para>
@@ -390,17 +385,17 @@
<para>
<literal>WRITE</literal> locks normally have higher priority than
<literal>READ</literal> locks to ensure that updates are processed
- as soon as possible. This means that if one thread obtains a
- <literal>READ</literal> lock and then another thread requests a
+ as soon as possible. This means that if one session obtains a
+ <literal>READ</literal> lock and then another session requests a
<literal>WRITE</literal> lock, subsequent <literal>READ</literal>
- lock requests wait until the thread that requested the
+ lock requests wait until the session that requested the
<literal>WRITE</literal> lock has obtained the lock and released it.
A request for a <literal>LOW_PRIORITY WRITE</literal> lock, by
contrast, allows subsequent <literal>READ</literal> lock requests by
- other threads to be satisfied first if they occur while the
+ other sessions to be satisfied first if they occur while the
<literal>LOW_PRIORITY WRITE</literal> request is waiting. You should
use <literal>LOW_PRIORITY WRITE</literal> locks only if you are sure
- that eventually there will be a time when no threads have a
+ that eventually there will be a time when no sessions have a
<literal>READ</literal> lock. For <literal>InnoDB</literal> tables
in transactional mode (autocommit = 0), a waiting
<literal>LOW_PRIORITY WRITE</literal> lock acts like a regular
@@ -434,7 +429,7 @@
<listitem>
<para>
- Lock one table at a time until the thread gets all locks.
+ Lock one table at a time until the session gets all locks.
</para>
</listitem>
@@ -445,10 +440,10 @@
however, other things you need to be aware of about this policy: If
you are using a <literal>LOW_PRIORITY WRITE</literal> lock for a
table, it means only that MySQL waits for this particular lock until
- there are no threads that want a <literal>READ</literal> lock. When
- the thread has gotten the <literal>WRITE</literal> lock and is
+ there are no sessions that want a <literal>READ</literal> lock. When
+ the session has gotten the <literal>WRITE</literal> lock and is
waiting to get the lock for the next table in the lock table list,
- all other threads wait for the <literal>WRITE</literal> lock to be
+ all other sessions wait for the <literal>WRITE</literal> lock to be
released. If this becomes a serious problem with your application,
you should consider converting some of your tables to
transaction-safe tables.
@@ -462,8 +457,8 @@
<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
+ not commit transactions automatically. Multiple sessions can acquire
+ a shared lock simultaneously. Only one session at a time can acquire
an exclusive lock.
</para>
@@ -590,7 +585,7 @@
</para>
<para>
- You can safely use <literal>KILL</literal> to terminate a thread
+ You can safely use <literal>KILL</literal> to terminate a session
that is waiting for a table lock. See <xref linkend="kill"/>.
</para>
@@ -632,9 +627,10 @@
<para>
Normally, you do not need to lock tables, because all single
- <literal>UPDATE</literal> statements are atomic; no other thread can
- interfere with any other currently executing SQL statement. However,
- there are a few cases when locking tables may provide an advantage:
+ <literal>UPDATE</literal> statements are atomic; no other session
+ can interfere with any other currently executing SQL statement.
+ However, there are a few cases when locking tables may provide an
+ advantage:
</para>
<itemizedlist>
@@ -651,9 +647,9 @@
</para>
<para>
- The downside to locking the tables is that no thread can update
+ The downside to locking the tables is that no session can update
a <literal>READ</literal>-locked table (including the one
- holding the lock) and no thread can access a
+ holding the lock) and no session can access a
<literal>WRITE</literal>-locked table other than the one holding
the lock.
</para>
@@ -663,7 +659,7 @@
<para>
If you are using tables for a non-transactional storage engine,
you must use <literal>LOCK TABLES</literal> if you want to
- ensure that no other thread modifies the tables between a
+ ensure that no other session modifies the tables between a
<literal>SELECT</literal> and an <literal>UPDATE</literal>. The
example shown here requires <literal>LOCK TABLES</literal> to
execute safely:
@@ -680,7 +676,7 @@
<para>
Without <literal>LOCK TABLES</literal>, it is possible that
- another thread might insert a new row in the
+ another session might insert a new row in the
<literal>trans</literal> table between execution of the
<literal>SELECT</literal> and <literal>UPDATE</literal>
statements.
Modified: trunk/refman-6.0/sql-syntax.xml
===================================================================
--- trunk/refman-6.0/sql-syntax.xml 2008-06-13 19:27:24 UTC (rev 10952)
+++ trunk/refman-6.0/sql-syntax.xml 2008-06-13 19:40:57 UTC (rev 10953)
Changed blocks: 2, Lines Added: 3, Lines Deleted: 3; 1230 bytes
@@ -5803,8 +5803,8 @@
the table is a <literal>TEMPORARY</literal> table. (Previously,
if other tables were locked, you could drop a table with a read
lock or no lock, which could lead to deadlocks between clients.
- The new stricter behavior means that some usage scenarios will
- fail when previously they did not.)
+ The current stricter behavior means that some usage scenarios
+ will fail when previously they did not.)
</para>
</section>
@@ -15605,7 +15605,7 @@
that thread (and all other threads) can only read from the
table. If a thread obtains a <literal>WRITE</literal> lock on a
table, only the thread holding the lock can write to the table
- (that thread can also read from the table). Other threads are
+ (that thread can also read from the table); other threads are
blocked from reading or writing the table until the lock has
been released.
</para>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r10953 - in trunk: . it/refman-5.1 pt/refman-5.1 refman-4.1 refman-5.0 refman-5.1 refman-6.0 | paul | 13 Jun |
