Author: paul
Date: 2008-11-26 19:07:28 +0100 (Wed, 26 Nov 2008)
New Revision: 12674
Log:
r36186@frost: paul | 2008-11-26 11:33:52 -0500
Better parallelism in isolation level descriptions
Modified:
trunk/refman-4.1/sql-syntax-transactions.xml
trunk/refman-5.0/sql-syntax-transactions.xml
trunk/refman-5.1/sql-syntax-transactions.xml
trunk/refman-6.0/sql-syntax-transactions.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:39854
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:36181
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:34596
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:39854
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:36186
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:34596
Modified: trunk/refman-4.1/sql-syntax-transactions.xml
===================================================================
--- trunk/refman-4.1/sql-syntax-transactions.xml 2008-11-26 17:18:38 UTC (rev 12673)
+++ trunk/refman-4.1/sql-syntax-transactions.xml 2008-11-26 18:07:28 UTC (rev 12674)
Changed blocks: 3, Lines Added: 19, Lines Deleted: 20; 3113 bytes
@@ -1210,9 +1210,9 @@
</para>
<para>
- A somewhat Oracle-like isolation level. Consistent
- (non-locking) reads behave as in Oracle: Each consistent read,
- even within the same transaction, sets and reads its own fresh
+ A somewhat Oracle-like isolation level with respect to
+ consistent (non-locking) reads: Each consistent read, even
+ within the same transaction, sets and reads its own fresh
snapshot. See <xref linkend="innodb-consistent-read"/>.
</para>
@@ -1255,10 +1255,22 @@
<para>
This is the default isolation level of
- <literal>InnoDB</literal>. For locking reads
- (<literal role="stmt">SELECT</literal> with <literal>FOR
- UPDATE</literal> or <literal>LOCK IN SHARE MODE</literal>),
- <literal role="stmt">UPDATE</literal>, and
+ <literal>InnoDB</literal>. For consistent reads, there is an
+ important difference from the <literal role="isolevel">READ
+ COMMITTED</literal> isolation level: All consistent reads
+ within the same transaction read the snapshot established by
+ the first read. This convention means that if you issue
+ several plain (non-locking)
+ <literal role="stmt">SELECT</literal> statements within the
+ same transaction, these <literal role="stmt">SELECT</literal>
+ statements are consistent also with respect to each other. See
+ <xref linkend="innodb-consistent-read"/>.
+ </para>
+
+ <para>
+ For locking reads (<literal role="stmt">SELECT</literal> with
+ <literal>FOR UPDATE</literal> or <literal>LOCK IN SHARE
+ MODE</literal>), <literal role="stmt">UPDATE</literal>, and
<literal role="stmt">DELETE</literal> statements, locking
depends on whether the statement uses a unique index with a
unique search condition, or a range-type search condition. For
@@ -1269,19 +1281,6 @@
index-record) locks to block insertions by other sessions into
the gaps covered by the range.
</para>
-
- <para>
- For consistent reads, there is an important difference from
- the <literal role="isolevel">READ COMMITTED</literal>
- isolation level: All consistent reads within the same
- transaction read the snapshot established by the first read.
- This convention means that if you issue several plain
- (non-locking) <literal role="stmt">SELECT</literal> statements
- within the same transaction, these
- <literal role="stmt">SELECT</literal> statements are
- consistent also with respect to each other. See
- <xref linkend="innodb-consistent-read"/>.
- </para>
</listitem>
<listitem>
Modified: trunk/refman-5.0/sql-syntax-transactions.xml
===================================================================
--- trunk/refman-5.0/sql-syntax-transactions.xml 2008-11-26 17:18:38 UTC (rev 12673)
+++ trunk/refman-5.0/sql-syntax-transactions.xml 2008-11-26 18:07:28 UTC (rev 12674)
Changed blocks: 3, Lines Added: 19, Lines Deleted: 20; 3113 bytes
@@ -1302,9 +1302,9 @@
</para>
<para>
- A somewhat Oracle-like isolation level. Consistent
- (non-locking) reads behave as in Oracle: Each consistent read,
- even within the same transaction, sets and reads its own fresh
+ A somewhat Oracle-like isolation level with respect to
+ consistent (non-locking) reads: Each consistent read, even
+ within the same transaction, sets and reads its own fresh
snapshot. See <xref linkend="innodb-consistent-read"/>.
</para>
@@ -1347,10 +1347,22 @@
<para>
This is the default isolation level of
- <literal>InnoDB</literal>. For locking reads
- (<literal role="stmt">SELECT</literal> with <literal>FOR
- UPDATE</literal> or <literal>LOCK IN SHARE MODE</literal>),
- <literal role="stmt">UPDATE</literal>, and
+ <literal>InnoDB</literal>. For consistent reads, there is an
+ important difference from the <literal role="isolevel">READ
+ COMMITTED</literal> isolation level: All consistent reads
+ within the same transaction read the snapshot established by
+ the first read. This convention means that if you issue
+ several plain (non-locking)
+ <literal role="stmt">SELECT</literal> statements within the
+ same transaction, these <literal role="stmt">SELECT</literal>
+ statements are consistent also with respect to each other. See
+ <xref linkend="innodb-consistent-read"/>.
+ </para>
+
+ <para>
+ For locking reads (<literal role="stmt">SELECT</literal> with
+ <literal>FOR UPDATE</literal> or <literal>LOCK IN SHARE
+ MODE</literal>), <literal role="stmt">UPDATE</literal>, and
<literal role="stmt">DELETE</literal> statements, locking
depends on whether the statement uses a unique index with a
unique search condition, or a range-type search condition. For
@@ -1361,19 +1373,6 @@
index-record) locks to block insertions by other sessions into
the gaps covered by the range.
</para>
-
- <para>
- For consistent reads, there is an important difference from
- the <literal role="isolevel">READ COMMITTED</literal>
- isolation level: All consistent reads within the same
- transaction read the snapshot established by the first read.
- This convention means that if you issue several plain
- (non-locking) <literal role="stmt">SELECT</literal> statements
- within the same transaction, these
- <literal role="stmt">SELECT</literal> statements are
- consistent also with respect to each other. See
- <xref linkend="innodb-consistent-read"/>.
- </para>
</listitem>
<listitem>
Modified: trunk/refman-5.1/sql-syntax-transactions.xml
===================================================================
--- trunk/refman-5.1/sql-syntax-transactions.xml 2008-11-26 17:18:38 UTC (rev 12673)
+++ trunk/refman-5.1/sql-syntax-transactions.xml 2008-11-26 18:07:28 UTC (rev 12674)
Changed blocks: 3, Lines Added: 19, Lines Deleted: 20; 3113 bytes
@@ -1370,9 +1370,9 @@
</para>
<para>
- A somewhat Oracle-like isolation level. Consistent
- (non-locking) reads behave as in Oracle: Each consistent read,
- even within the same transaction, sets and reads its own fresh
+ A somewhat Oracle-like isolation level with respect to
+ consistent (non-locking) reads: Each consistent read, even
+ within the same transaction, sets and reads its own fresh
snapshot. See <xref linkend="innodb-consistent-read"/>.
</para>
@@ -1415,10 +1415,22 @@
<para>
This is the default isolation level of
- <literal>InnoDB</literal>. For locking reads
- (<literal role="stmt">SELECT</literal> with <literal>FOR
- UPDATE</literal> or <literal>LOCK IN SHARE MODE</literal>),
- <literal role="stmt">UPDATE</literal>, and
+ <literal>InnoDB</literal>. For consistent reads, there is an
+ important difference from the <literal role="isolevel">READ
+ COMMITTED</literal> isolation level: All consistent reads
+ within the same transaction read the snapshot established by
+ the first read. This convention means that if you issue
+ several plain (non-locking)
+ <literal role="stmt">SELECT</literal> statements within the
+ same transaction, these <literal role="stmt">SELECT</literal>
+ statements are consistent also with respect to each other. See
+ <xref linkend="innodb-consistent-read"/>.
+ </para>
+
+ <para>
+ For locking reads (<literal role="stmt">SELECT</literal> with
+ <literal>FOR UPDATE</literal> or <literal>LOCK IN SHARE
+ MODE</literal>), <literal role="stmt">UPDATE</literal>, and
<literal role="stmt">DELETE</literal> statements, locking
depends on whether the statement uses a unique index with a
unique search condition, or a range-type search condition. For
@@ -1429,19 +1441,6 @@
index-record) locks to block insertions by other sessions into
the gaps covered by the range.
</para>
-
- <para>
- For consistent reads, there is an important difference from
- the <literal role="isolevel">READ COMMITTED</literal>
- isolation level: All consistent reads within the same
- transaction read the snapshot established by the first read.
- This convention means that if you issue several plain
- (non-locking) <literal role="stmt">SELECT</literal> statements
- within the same transaction, these
- <literal role="stmt">SELECT</literal> statements are
- consistent also with respect to each other. See
- <xref linkend="innodb-consistent-read"/>.
- </para>
</listitem>
<listitem>
Modified: trunk/refman-6.0/sql-syntax-transactions.xml
===================================================================
--- trunk/refman-6.0/sql-syntax-transactions.xml 2008-11-26 17:18:38 UTC (rev 12673)
+++ trunk/refman-6.0/sql-syntax-transactions.xml 2008-11-26 18:07:28 UTC (rev 12674)
Changed blocks: 3, Lines Added: 19, Lines Deleted: 20; 3113 bytes
@@ -2039,9 +2039,9 @@
</para>
<para>
- A somewhat Oracle-like isolation level. Consistent
- (non-locking) reads behave as in Oracle: Each consistent read,
- even within the same transaction, sets and reads its own fresh
+ A somewhat Oracle-like isolation level with respect to
+ consistent (non-locking) reads: Each consistent read, even
+ within the same transaction, sets and reads its own fresh
snapshot. See <xref linkend="innodb-consistent-read"/>.
</para>
@@ -2084,10 +2084,22 @@
<para>
This is the default isolation level of
- <literal>InnoDB</literal>. For locking reads
- (<literal role="stmt">SELECT</literal> with <literal>FOR
- UPDATE</literal> or <literal>LOCK IN SHARE MODE</literal>),
- <literal role="stmt">UPDATE</literal>, and
+ <literal>InnoDB</literal>. For consistent reads, there is an
+ important difference from the <literal role="isolevel">READ
+ COMMITTED</literal> isolation level: All consistent reads
+ within the same transaction read the snapshot established by
+ the first read. This convention means that if you issue
+ several plain (non-locking)
+ <literal role="stmt">SELECT</literal> statements within the
+ same transaction, these <literal role="stmt">SELECT</literal>
+ statements are consistent also with respect to each other. See
+ <xref linkend="innodb-consistent-read"/>.
+ </para>
+
+ <para>
+ For locking reads (<literal role="stmt">SELECT</literal> with
+ <literal>FOR UPDATE</literal> or <literal>LOCK IN SHARE
+ MODE</literal>), <literal role="stmt">UPDATE</literal>, and
<literal role="stmt">DELETE</literal> statements, locking
depends on whether the statement uses a unique index with a
unique search condition, or a range-type search condition. For
@@ -2098,19 +2110,6 @@
index-record) locks to block insertions by other sessions into
the gaps covered by the range.
</para>
-
- <para>
- For consistent reads, there is an important difference from
- the <literal role="isolevel">READ COMMITTED</literal>
- isolation level: All consistent reads within the same
- transaction read the snapshot established by the first read.
- This convention means that if you issue several plain
- (non-locking) <literal role="stmt">SELECT</literal> statements
- within the same transaction, these
- <literal role="stmt">SELECT</literal> statements are
- consistent also with respect to each other. See
- <xref linkend="innodb-consistent-read"/>.
- </para>
</listitem>
<listitem>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r12674 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-6.0 | paul.dubois | 26 Nov |
