Author: mcbrown
Date: 2008-04-09 10:42:29 +0200 (Wed, 09 Apr 2008)
New Revision: 10432
Log:
Moving the transaction level to a generic place so that we can refer to it from other parts of the documentation
Modified:
trunk/refman-5.0/se-innodb-core.xml
trunk/refman-5.0/sql-syntax.xml
trunk/refman-5.1/se-innodb-core.xml
trunk/refman-5.1/sql-syntax.xml
trunk/refman-6.0/se-innodb-core.xml
trunk/refman-6.0/sql-syntax.xml
Modified: trunk/refman-5.0/se-innodb-core.xml
===================================================================
--- trunk/refman-5.0/se-innodb-core.xml 2008-04-08 23:15:07 UTC (rev 10431)
+++ trunk/refman-5.0/se-innodb-core.xml 2008-04-09 08:42:29 UTC (rev 10432)
Changed blocks: 1, Lines Added: 4, Lines Deleted: 92; 4312 bytes
@@ -4149,99 +4149,11 @@
<literal>InnoDB</literal> follows:
</para>
- <itemizedlist>
+ <para>
+ For a detailed description of isolated levels, see
+ <xref linkend="set-transaction"/>.
+ </para>
- <listitem>
- <para>
- <literal>READ UNCOMMITTED</literal>
- </para>
-
- <para>
- <literal>SELECT</literal> statements are performed in a
- non-locking fashion, but a possible earlier version of a
- record might be used. Thus, using this isolation level, such
- reads are not consistent. This is also called a <quote>dirty
- read.</quote> Otherwise, this isolation level works like
- <literal>READ COMMITTED</literal>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <literal>READ COMMITTED</literal>
- </para>
-
- <para>
- A somewhat Oracle-like isolation level. All <literal>SELECT
- ... FOR UPDATE</literal> and <literal>SELECT ... LOCK IN
- SHARE MODE</literal> statements lock only the index records,
- not the gaps before them, and thus allow the free insertion
- of new records next to locked records.
- <literal>UPDATE</literal> and <literal>DELETE</literal>
- statements using a unique index with a unique search
- condition lock only the index record found, not the gap
- before it. In range-type <literal>UPDATE</literal> and
- <literal>DELETE</literal> statements,
- <literal>InnoDB</literal> must set next-key or gap locks and
- block insertions by other users to the gaps covered by the
- range. This is necessary because <quote>phantom rows</quote>
- must be blocked for MySQL replication and recovery to work.
- </para>
-
- <para>
- Consistent reads behave as in Oracle: Each consistent read,
- even within the same transaction, sets and reads its own
- fresh snapshot. See
- <xref linkend="innodb-consistent-read"/>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <literal>REPEATABLE READ</literal>
- </para>
-
- <para>
- This is the default isolation level of
- <literal>InnoDB</literal>. <literal>SELECT ... FOR
- UPDATE</literal>, <literal>SELECT ... LOCK IN SHARE
- MODE</literal>, <literal>UPDATE</literal>, and
- <literal>DELETE</literal> statements that use a unique index
- with a unique search condition lock only the index record
- found, not the gap before it. With other search conditions,
- these operations employ next-key locking, locking the index
- range scanned with next-key or gap locks, and block new
- insertions by other users.
- </para>
-
- <para>
- In consistent reads, there is an important difference from
- the <literal>READ COMMITTED</literal> isolation level: All
- consistent reads within the same transaction read the same
- snapshot established by the first read. This convention
- means that if you issue several plain
- <literal>SELECT</literal> statements within the same
- transaction, these <literal>SELECT</literal> statements are
- consistent also with respect to each other. See
- <xref linkend="innodb-consistent-read"/>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <literal>SERIALIZABLE</literal>
- </para>
-
- <para>
- This level is like <literal>REPEATABLE READ</literal>, but
- <literal>InnoDB</literal> implicitly converts all plain
- <literal>SELECT</literal> statements to <literal>SELECT ...
- LOCK IN SHARE MODE</literal>.
- </para>
- </listitem>
-
- </itemizedlist>
-
</section>
<section id="innodb-consistent-read">
Modified: trunk/refman-5.0/sql-syntax.xml
===================================================================
--- trunk/refman-5.0/sql-syntax.xml 2008-04-08 23:15:07 UTC (rev 10431)
+++ trunk/refman-5.0/sql-syntax.xml 2008-04-09 08:42:29 UTC (rev 10432)
Changed blocks: 1, Lines Added: 98, Lines Deleted: 0; 4307 bytes
@@ -12716,6 +12716,104 @@
<xref linkend="server-options"/>.
</para>
+ <para>
+ A detailed list of the types supported by MySQL and the various
+ storage engines follows:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>READ UNCOMMITTED</literal>
+ </para>
+
+ <para>
+ <literal>SELECT</literal> statements are performed in a
+ non-locking fashion, but a possible earlier version of a
+ record might be used. Thus, using this isolation level, such
+ reads are not consistent. This is also called a <quote>dirty
+ read.</quote> Otherwise, this isolation level works like
+ <literal>READ COMMITTED</literal>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>READ COMMITTED</literal>
+ </para>
+
+ <para>
+ A somewhat Oracle-like isolation level. All <literal>SELECT
+ ... FOR UPDATE</literal> and <literal>SELECT ... LOCK IN
+ SHARE MODE</literal> statements lock only the index records,
+ not the gaps before them, and thus allow the free insertion
+ of new records next to locked records.
+ <literal>UPDATE</literal> and <literal>DELETE</literal>
+ statements using a unique index with a unique search
+ condition lock only the index record found, not the gap
+ before it. In range-type <literal>UPDATE</literal> and
+ <literal>DELETE</literal> statements,
+ <literal>InnoDB</literal> must set next-key or gap locks and
+ block insertions by other users to the gaps covered by the
+ range. This is necessary because <quote>phantom rows</quote>
+ must be blocked for MySQL replication and recovery to work.
+ </para>
+
+ <para>
+ Consistent reads behave as in Oracle: Each consistent read,
+ even within the same transaction, sets and reads its own
+ fresh snapshot. See
+ <xref linkend="innodb-consistent-read"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>REPEATABLE READ</literal>
+ </para>
+
+ <para>
+ This is the default isolation level of
+ <literal>InnoDB</literal>. <literal>SELECT ... FOR
+ UPDATE</literal>, <literal>SELECT ... LOCK IN SHARE
+ MODE</literal>, <literal>UPDATE</literal>, and
+ <literal>DELETE</literal> statements that use a unique index
+ with a unique search condition lock only the index record
+ found, not the gap before it. With other search conditions,
+ these operations employ next-key locking, locking the index
+ range scanned with next-key or gap locks, and block new
+ insertions by other users.
+ </para>
+
+ <para>
+ In consistent reads, there is an important difference from
+ the <literal>READ COMMITTED</literal> isolation level: All
+ consistent reads within the same transaction read the same
+ snapshot established by the first read. This convention
+ means that if you issue several plain
+ <literal>SELECT</literal> statements within the same
+ transaction, these <literal>SELECT</literal> statements are
+ consistent also with respect to each other. See
+ <xref linkend="innodb-consistent-read"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>SERIALIZABLE</literal>
+ </para>
+
+ <para>
+ This level is like <literal>REPEATABLE READ</literal>, but
+ <literal>InnoDB</literal> implicitly converts all plain
+ <literal>SELECT</literal> statements to <literal>SELECT ...
+ LOCK IN SHARE MODE</literal>.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
<remark role="help-description-end"/>
</section>
Modified: trunk/refman-5.1/se-innodb-core.xml
===================================================================
--- trunk/refman-5.1/se-innodb-core.xml 2008-04-08 23:15:07 UTC (rev 10431)
+++ trunk/refman-5.1/se-innodb-core.xml 2008-04-09 08:42:29 UTC (rev 10432)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 105; 4792 bytes
@@ -4814,113 +4814,10 @@
</para>
<para>
- A detailed description of each isolation level in
- <literal>InnoDB</literal> follows:
+ For a detailed description of isolated levels, see
+ <xref linkend="set-transaction"/>.
</para>
- <itemizedlist>
-
- <listitem>
- <para>
- <literal>READ UNCOMMITTED</literal>
- </para>
-
- <para>
- <literal>SELECT</literal> statements are performed in a
- non-locking fashion, but a possible earlier version of a
- record might be used. Thus, using this isolation level, such
- reads are not consistent. This is also called a <quote>dirty
- read.</quote> Otherwise, this isolation level works like
- <literal>READ COMMITTED</literal>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <literal>READ COMMITTED</literal>
- </para>
-
- <para>
- A somewhat Oracle-like isolation level. All <literal>SELECT
- ... FOR UPDATE</literal> and <literal>SELECT ... LOCK IN
- SHARE MODE</literal> statements lock only the index records,
- not the gaps before them, and thus allow the free insertion
- of new records next to locked records.
- <literal>UPDATE</literal> and <literal>DELETE</literal>
- statements using a unique index with a unique search
- condition lock only the index record found, not the gap
- before it. In range-type <literal>UPDATE</literal> and
- <literal>DELETE</literal> statements,
- <literal>InnoDB</literal> must set next-key or gap locks and
- block insertions by other users to the gaps covered by the
- range. This is necessary because <quote>phantom rows</quote>
- must be blocked for MySQL replication and recovery to work.
- </para>
-
- <para>
- Consistent reads behave as in Oracle: Each consistent read,
- even within the same transaction, sets and reads its own
- fresh snapshot. See
- <xref linkend="innodb-consistent-read"/>.
- </para>
-
- <note>
- <para>
- As of MySQL 5.1, if you use <literal>READ
- COMMITTED</literal> (which is equivalent to
- <literal>innodb_locks_unsafe_for_binlog</literal> in 5.0),
- you <emphasis>must</emphasis> use row-based binary
- logging.
- </para>
- </note>
- </listitem>
-
- <listitem>
- <para>
- <literal>REPEATABLE READ</literal>
- </para>
-
- <para>
- This is the default isolation level of
- <literal>InnoDB</literal>. <literal>SELECT ... FOR
- UPDATE</literal>, <literal>SELECT ... LOCK IN SHARE
- MODE</literal>, <literal>UPDATE</literal>, and
- <literal>DELETE</literal> statements that use a unique index
- with a unique search condition lock only the index record
- found, not the gap before it. With other search conditions,
- these operations employ next-key locking, locking the index
- range scanned with next-key or gap locks, and block new
- insertions by other users.
- </para>
-
- <para>
- In consistent reads, there is an important difference from
- the <literal>READ COMMITTED</literal> isolation level: All
- consistent reads within the same transaction read the same
- snapshot established by the first read. This convention
- means that if you issue several plain
- <literal>SELECT</literal> statements within the same
- transaction, these <literal>SELECT</literal> statements are
- consistent also with respect to each other. See
- <xref linkend="innodb-consistent-read"/>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <literal>SERIALIZABLE</literal>
- </para>
-
- <para>
- This level is like <literal>REPEATABLE READ</literal>, but
- <literal>InnoDB</literal> implicitly converts all plain
- <literal>SELECT</literal> statements to <literal>SELECT ...
- LOCK IN SHARE MODE</literal>.
- </para>
- </listitem>
-
- </itemizedlist>
-
<para>
In MySQL ¤t-series;, if the <literal>READ
COMMITTED</literal> isolation level is used or the
Modified: trunk/refman-5.1/sql-syntax.xml
===================================================================
--- trunk/refman-5.1/sql-syntax.xml 2008-04-08 23:15:07 UTC (rev 10431)
+++ trunk/refman-5.1/sql-syntax.xml 2008-04-09 08:42:29 UTC (rev 10432)
Changed blocks: 1, Lines Added: 108, Lines Deleted: 0; 4657 bytes
@@ -15304,6 +15304,114 @@
<xref linkend="server-options"/>.
</para>
+ <para>
+ A detailed list of the types supported by MySQL and the various
+ storage engines follows:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>READ UNCOMMITTED</literal>
+ </para>
+
+ <para>
+ <literal>SELECT</literal> statements are performed in a
+ non-locking fashion, but a possible earlier version of a
+ record might be used. Thus, using this isolation level, such
+ reads are not consistent. This is also called a <quote>dirty
+ read.</quote> Otherwise, this isolation level works like
+ <literal>READ COMMITTED</literal>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>READ COMMITTED</literal>
+ </para>
+
+ <para>
+ A somewhat Oracle-like isolation level. All <literal>SELECT
+ ... FOR UPDATE</literal> and <literal>SELECT ... LOCK IN
+ SHARE MODE</literal> statements lock only the index records,
+ not the gaps before them, and thus allow the free insertion
+ of new records next to locked records.
+ <literal>UPDATE</literal> and <literal>DELETE</literal>
+ statements using a unique index with a unique search
+ condition lock only the index record found, not the gap
+ before it. In range-type <literal>UPDATE</literal> and
+ <literal>DELETE</literal> statements,
+ <literal>InnoDB</literal> must set next-key or gap locks and
+ block insertions by other users to the gaps covered by the
+ range. This is necessary because <quote>phantom rows</quote>
+ must be blocked for MySQL replication and recovery to work.
+ </para>
+
+ <para>
+ Consistent reads behave as in Oracle: Each consistent read,
+ even within the same transaction, sets and reads its own
+ fresh snapshot. See
+ <xref linkend="innodb-consistent-read"/>.
+ </para>
+
+ <note>
+ <para>
+ As of MySQL 5.1, if you use <literal>READ
+ COMMITTED</literal> (which is equivalent to
+ <literal>innodb_locks_unsafe_for_binlog</literal> in 5.0),
+ you <emphasis>must</emphasis> use row-based binary
+ logging.
+ </para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>REPEATABLE READ</literal>
+ </para>
+
+ <para>
+ This is the default isolation level of
+ <literal>InnoDB</literal>. <literal>SELECT ... FOR
+ UPDATE</literal>, <literal>SELECT ... LOCK IN SHARE
+ MODE</literal>, <literal>UPDATE</literal>, and
+ <literal>DELETE</literal> statements that use a unique index
+ with a unique search condition lock only the index record
+ found, not the gap before it. With other search conditions,
+ these operations employ next-key locking, locking the index
+ range scanned with next-key or gap locks, and block new
+ insertions by other users.
+ </para>
+
+ <para>
+ In consistent reads, there is an important difference from
+ the <literal>READ COMMITTED</literal> isolation level: All
+ consistent reads within the same transaction read the same
+ snapshot established by the first read. This convention
+ means that if you issue several plain
+ <literal>SELECT</literal> statements within the same
+ transaction, these <literal>SELECT</literal> statements are
+ consistent also with respect to each other. See
+ <xref linkend="innodb-consistent-read"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>SERIALIZABLE</literal>
+ </para>
+
+ <para>
+ This level is like <literal>REPEATABLE READ</literal>, but
+ <literal>InnoDB</literal> implicitly converts all plain
+ <literal>SELECT</literal> statements to <literal>SELECT ...
+ LOCK IN SHARE MODE</literal>.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
<remark role="help-description-end"/>
</section>
Modified: trunk/refman-6.0/se-innodb-core.xml
===================================================================
--- trunk/refman-6.0/se-innodb-core.xml 2008-04-08 23:15:07 UTC (rev 10431)
+++ trunk/refman-6.0/se-innodb-core.xml 2008-04-09 08:42:29 UTC (rev 10432)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 105; 4781 bytes
@@ -4761,113 +4761,10 @@
</para>
<para>
- A detailed description of each isolation level in
- <literal>InnoDB</literal> follows:
+ For a detailed description of isolated levels, see
+ <xref linkend="set-transaction"/>.
</para>
- <itemizedlist>
-
- <listitem>
- <para>
- <literal>READ UNCOMMITTED</literal>
- </para>
-
- <para>
- <literal>SELECT</literal> statements are performed in a
- non-locking fashion, but a possible earlier version of a
- record might be used. Thus, using this isolation level, such
- reads are not consistent. This is also called a <quote>dirty
- read.</quote> Otherwise, this isolation level works like
- <literal>READ COMMITTED</literal>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <literal>READ COMMITTED</literal>
- </para>
-
- <para>
- A somewhat Oracle-like isolation level. All <literal>SELECT
- ... FOR UPDATE</literal> and <literal>SELECT ... LOCK IN
- SHARE MODE</literal> statements lock only the index records,
- not the gaps before them, and thus allow the free insertion
- of new records next to locked records.
- <literal>UPDATE</literal> and <literal>DELETE</literal>
- statements using a unique index with a unique search
- condition lock only the index record found, not the gap
- before it. In range-type <literal>UPDATE</literal> and
- <literal>DELETE</literal> statements,
- <literal>InnoDB</literal> must set next-key or gap locks and
- block insertions by other users to the gaps covered by the
- range. This is necessary because <quote>phantom rows</quote>
- must be blocked for MySQL replication and recovery to work.
- </para>
-
- <para>
- Consistent reads behave as in Oracle: Each consistent read,
- even within the same transaction, sets and reads its own
- fresh snapshot. See
- <xref linkend="innodb-consistent-read"/>.
- </para>
-
- <note>
- <para>
- If you use <literal>READ COMMITTED</literal> (which is
- equivalent to
- <literal>innodb_locks_unsafe_for_binlog</literal> in MySQL
- 5.0), you <emphasis>must</emphasis> use row-based binary
- logging.
- </para>
- </note>
- </listitem>
-
- <listitem>
- <para>
- <literal>REPEATABLE READ</literal>
- </para>
-
- <para>
- This is the default isolation level of
- <literal>InnoDB</literal>. <literal>SELECT ... FOR
- UPDATE</literal>, <literal>SELECT ... LOCK IN SHARE
- MODE</literal>, <literal>UPDATE</literal>, and
- <literal>DELETE</literal> statements that use a unique index
- with a unique search condition lock only the index record
- found, not the gap before it. With other search conditions,
- these operations employ next-key locking, locking the index
- range scanned with next-key or gap locks, and block new
- insertions by other users.
- </para>
-
- <para>
- In consistent reads, there is an important difference from
- the <literal>READ COMMITTED</literal> isolation level: All
- consistent reads within the same transaction read the same
- snapshot established by the first read. This convention
- means that if you issue several plain
- <literal>SELECT</literal> statements within the same
- transaction, these <literal>SELECT</literal> statements are
- consistent also with respect to each other. See
- <xref linkend="innodb-consistent-read"/>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <literal>SERIALIZABLE</literal>
- </para>
-
- <para>
- This level is like <literal>REPEATABLE READ</literal>, but
- <literal>InnoDB</literal> implicitly converts all plain
- <literal>SELECT</literal> statements to <literal>SELECT ...
- LOCK IN SHARE MODE</literal>.
- </para>
- </listitem>
-
- </itemizedlist>
-
<para>
In MySQL ¤t-series;, if the <literal>READ
COMMITTED</literal> isolation level is used or the
Modified: trunk/refman-6.0/sql-syntax.xml
===================================================================
--- trunk/refman-6.0/sql-syntax.xml 2008-04-08 23:15:07 UTC (rev 10431)
+++ trunk/refman-6.0/sql-syntax.xml 2008-04-09 08:42:29 UTC (rev 10432)
Changed blocks: 1, Lines Added: 108, Lines Deleted: 0; 4646 bytes
@@ -15813,6 +15813,114 @@
<xref linkend="server-options"/>.
</para>
+ <para>
+ A detailed list of the types supported by MySQL and the various
+ storage engines follows:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>READ UNCOMMITTED</literal>
+ </para>
+
+ <para>
+ <literal>SELECT</literal> statements are performed in a
+ non-locking fashion, but a possible earlier version of a
+ record might be used. Thus, using this isolation level, such
+ reads are not consistent. This is also called a <quote>dirty
+ read.</quote> Otherwise, this isolation level works like
+ <literal>READ COMMITTED</literal>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>READ COMMITTED</literal>
+ </para>
+
+ <para>
+ A somewhat Oracle-like isolation level. All <literal>SELECT
+ ... FOR UPDATE</literal> and <literal>SELECT ... LOCK IN
+ SHARE MODE</literal> statements lock only the index records,
+ not the gaps before them, and thus allow the free insertion
+ of new records next to locked records.
+ <literal>UPDATE</literal> and <literal>DELETE</literal>
+ statements using a unique index with a unique search
+ condition lock only the index record found, not the gap
+ before it. In range-type <literal>UPDATE</literal> and
+ <literal>DELETE</literal> statements,
+ <literal>InnoDB</literal> must set next-key or gap locks and
+ block insertions by other users to the gaps covered by the
+ range. This is necessary because <quote>phantom rows</quote>
+ must be blocked for MySQL replication and recovery to work.
+ </para>
+
+ <para>
+ Consistent reads behave as in Oracle: Each consistent read,
+ even within the same transaction, sets and reads its own
+ fresh snapshot. See
+ <xref linkend="innodb-consistent-read"/>.
+ </para>
+
+ <note>
+ <para>
+ If you use <literal>READ COMMITTED</literal> (which is
+ equivalent to
+ <literal>innodb_locks_unsafe_for_binlog</literal> in MySQL
+ 5.0), you <emphasis>must</emphasis> use row-based binary
+ logging.
+ </para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>REPEATABLE READ</literal>
+ </para>
+
+ <para>
+ This is the default isolation level of
+ <literal>InnoDB</literal>. <literal>SELECT ... FOR
+ UPDATE</literal>, <literal>SELECT ... LOCK IN SHARE
+ MODE</literal>, <literal>UPDATE</literal>, and
+ <literal>DELETE</literal> statements that use a unique index
+ with a unique search condition lock only the index record
+ found, not the gap before it. With other search conditions,
+ these operations employ next-key locking, locking the index
+ range scanned with next-key or gap locks, and block new
+ insertions by other users.
+ </para>
+
+ <para>
+ In consistent reads, there is an important difference from
+ the <literal>READ COMMITTED</literal> isolation level: All
+ consistent reads within the same transaction read the same
+ snapshot established by the first read. This convention
+ means that if you issue several plain
+ <literal>SELECT</literal> statements within the same
+ transaction, these <literal>SELECT</literal> statements are
+ consistent also with respect to each other. See
+ <xref linkend="innodb-consistent-read"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>SERIALIZABLE</literal>
+ </para>
+
+ <para>
+ This level is like <literal>REPEATABLE READ</literal>, but
+ <literal>InnoDB</literal> implicitly converts all plain
+ <literal>SELECT</literal> statements to <literal>SELECT ...
+ LOCK IN SHARE MODE</literal>.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
<remark role="help-description-end"/>
</section>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r10432 - in trunk: refman-5.0 refman-5.1 refman-6.0 | mcbrown | 9 Apr |
