Author: paul
Date: 2008-11-07 20:36:45 +0100 (Fri, 07 Nov 2008)
New Revision: 12340
Log:
r35431@frost: paul | 2008-11-07 13:35:44 -0500
General InnoDB revisions
Modified:
trunk/refman-4.1/se-innodb-core.xml
trunk/refman-5.0/se-innodb-core.xml
trunk/refman-5.1/se-innodb-core.xml
trunk/refman-6.0/se-innodb-core.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:35425
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:34100
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:39854
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:35431
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:34100
Modified: trunk/refman-4.1/se-innodb-core.xml
===================================================================
--- trunk/refman-4.1/se-innodb-core.xml 2008-11-07 19:17:08 UTC (rev 12339)
+++ trunk/refman-4.1/se-innodb-core.xml 2008-11-07 19:36:45 UTC (rev 12340)
Changed blocks: 2, Lines Added: 47, Lines Deleted: 27; 5068 bytes
@@ -4367,20 +4367,21 @@
<para>
In some circumstances, a consistent read is not convenient. For
- example, you might want to add a new row into your table
- <literal>child</literal>, and make sure that the child has a
- parent in table <literal>parent</literal>. The following example
- shows how to implement referential integrity in your application
- code.
+ example, you might want to insert a new row into your table
+ <literal>child</literal>, and make sure that the child row has a
+ parent row in table <literal>parent</literal>. The following
+ example describes how to implement referential integrity in your
+ application code.
</para>
<para>
Suppose that you use a consistent read to read the table
- <literal>parent</literal> and indeed see the parent of the child
- in the table. Can you safely add the child row to table
- <literal>child</literal>? No, because it may happen that
- meanwhile some other user deletes the parent row from the table
- <literal>parent</literal> without you being aware of it.
+ <literal>parent</literal> and indeed see the parent row of the
+ to-be-inserted child row in the table. Can you safely insert the
+ child row to table <literal>child</literal>? No, because it is
+ possible for some other user to delete the parent row from the
+ table <literal>parent</literal> in the meantime without you
+ being aware of it.
</para>
<para>
@@ -4399,40 +4400,59 @@
A shared mode lock prevents others from updating or deleting the
row we have read. Also, if the latest data belongs to a yet
uncommitted transaction of another client connection, we wait
- until that transaction commits. After we see that the preceding
- query returns the parent <literal>'Jones'</literal>, we can
- safely add the child record to the <literal>child</literal>
- table and commit our transaction.
+ until that transaction commits. After we see that the
+ <literal>LOCK IN SHARE MODE</literal> query returns the parent
+ <literal>'Jones'</literal>, we can safely add the child record
+ to the <literal>child</literal> table and commit our
+ transaction.
</para>
<para>
Let us look at another example: We have an integer counter field
in a table <literal>child_codes</literal> that we use to assign
a unique identifier to each child added to table
- <literal>child</literal>. Obviously, using a consistent read or
- a shared mode read to read the present value of the counter is
- not a good idea because two users of the database may then see
- the same value for the counter, and a duplicate-key error occurs
- if two users attempt to add children with the same identifier to
- the table.
+ <literal>child</literal>. Using a consistent read or a shared
+ mode read to read the present value of the counter is not a good
+ idea because two users of the database may then see the same
+ value for the counter, and a duplicate-key error occurs if two
+ users attempt to add children with the same identifier to the
+ table.
</para>
<para>
Here, <literal>LOCK IN SHARE MODE</literal> is not a good
solution because if two users read the counter at the same time,
- at least one of them ends up in deadlock when attempting to
+ at least one of them ends up in deadlock when it attempts to
update the counter.
</para>
<para>
- In this case, there are two good ways to implement the reading
- and incrementing of the counter: (1) update the counter first by
- incrementing it by 1 and only after that read it, or (2) read
- the counter first with a lock mode <literal>FOR
- UPDATE</literal>, and increment after that. The latter approach
- can be implemented as follows:
+ In this case, there are two good ways to implement reading and
+ incrementing the counter:
</para>
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Update the counter first by incrementing it by 1 and read it
+ only after that.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Read the counter first with a lock mode of <literal>FOR
+ UPDATE</literal>, and increment the counter after that.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ The latter approach can be implemented as follows:
+ </para>
+
<programlisting>
SELECT counter_field FROM child_codes FOR UPDATE;
UPDATE child_codes SET counter_field = counter_field + 1;
Modified: trunk/refman-5.0/se-innodb-core.xml
===================================================================
--- trunk/refman-5.0/se-innodb-core.xml 2008-11-07 19:17:08 UTC (rev 12339)
+++ trunk/refman-5.0/se-innodb-core.xml 2008-11-07 19:36:45 UTC (rev 12340)
Changed blocks: 2, Lines Added: 47, Lines Deleted: 27; 5068 bytes
@@ -4434,20 +4434,21 @@
<para>
In some circumstances, a consistent read is not convenient. For
- example, you might want to add a new row into your table
- <literal>child</literal>, and make sure that the child has a
- parent in table <literal>parent</literal>. The following example
- shows how to implement referential integrity in your application
- code.
+ example, you might want to insert a new row into your table
+ <literal>child</literal>, and make sure that the child row has a
+ parent row in table <literal>parent</literal>. The following
+ example describes how to implement referential integrity in your
+ application code.
</para>
<para>
Suppose that you use a consistent read to read the table
- <literal>parent</literal> and indeed see the parent of the child
- in the table. Can you safely add the child row to table
- <literal>child</literal>? No, because it may happen that
- meanwhile some other user deletes the parent row from the table
- <literal>parent</literal> without you being aware of it.
+ <literal>parent</literal> and indeed see the parent row of the
+ to-be-inserted child row in the table. Can you safely insert the
+ child row to table <literal>child</literal>? No, because it is
+ possible for some other user to delete the parent row from the
+ table <literal>parent</literal> in the meantime without you
+ being aware of it.
</para>
<para>
@@ -4466,40 +4467,59 @@
A shared mode lock prevents others from updating or deleting the
row we have read. Also, if the latest data belongs to a yet
uncommitted transaction of another client connection, we wait
- until that transaction commits. After we see that the preceding
- query returns the parent <literal>'Jones'</literal>, we can
- safely add the child record to the <literal>child</literal>
- table and commit our transaction.
+ until that transaction commits. After we see that the
+ <literal>LOCK IN SHARE MODE</literal> query returns the parent
+ <literal>'Jones'</literal>, we can safely add the child record
+ to the <literal>child</literal> table and commit our
+ transaction.
</para>
<para>
Let us look at another example: We have an integer counter field
in a table <literal>child_codes</literal> that we use to assign
a unique identifier to each child added to table
- <literal>child</literal>. Obviously, using a consistent read or
- a shared mode read to read the present value of the counter is
- not a good idea because two users of the database may then see
- the same value for the counter, and a duplicate-key error occurs
- if two users attempt to add children with the same identifier to
- the table.
+ <literal>child</literal>. Using a consistent read or a shared
+ mode read to read the present value of the counter is not a good
+ idea because two users of the database may then see the same
+ value for the counter, and a duplicate-key error occurs if two
+ users attempt to add children with the same identifier to the
+ table.
</para>
<para>
Here, <literal>LOCK IN SHARE MODE</literal> is not a good
solution because if two users read the counter at the same time,
- at least one of them ends up in deadlock when attempting to
+ at least one of them ends up in deadlock when it attempts to
update the counter.
</para>
<para>
- In this case, there are two good ways to implement the reading
- and incrementing of the counter: (1) update the counter first by
- incrementing it by 1 and only after that read it, or (2) read
- the counter first with a lock mode <literal>FOR
- UPDATE</literal>, and increment after that. The latter approach
- can be implemented as follows:
+ In this case, there are two good ways to implement reading and
+ incrementing the counter:
</para>
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Update the counter first by incrementing it by 1 and read it
+ only after that.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Read the counter first with a lock mode of <literal>FOR
+ UPDATE</literal>, and increment the counter after that.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ The latter approach can be implemented as follows:
+ </para>
+
<programlisting>
SELECT counter_field FROM child_codes FOR UPDATE;
UPDATE child_codes SET counter_field = counter_field + 1;
Modified: trunk/refman-5.1/se-innodb-core.xml
===================================================================
--- trunk/refman-5.1/se-innodb-core.xml 2008-11-07 19:17:08 UTC (rev 12339)
+++ trunk/refman-5.1/se-innodb-core.xml 2008-11-07 19:36:45 UTC (rev 12340)
Changed blocks: 2, Lines Added: 47, Lines Deleted: 27; 5068 bytes
@@ -5143,20 +5143,21 @@
<para>
In some circumstances, a consistent read is not convenient. For
- example, you might want to add a new row into your table
- <literal>child</literal>, and make sure that the child has a
- parent in table <literal>parent</literal>. The following example
- shows how to implement referential integrity in your application
- code.
+ example, you might want to insert a new row into your table
+ <literal>child</literal>, and make sure that the child row has a
+ parent row in table <literal>parent</literal>. The following
+ example describes how to implement referential integrity in your
+ application code.
</para>
<para>
Suppose that you use a consistent read to read the table
- <literal>parent</literal> and indeed see the parent of the child
- in the table. Can you safely add the child row to table
- <literal>child</literal>? No, because it may happen that
- meanwhile some other user deletes the parent row from the table
- <literal>parent</literal> without you being aware of it.
+ <literal>parent</literal> and indeed see the parent row of the
+ to-be-inserted child row in the table. Can you safely insert the
+ child row to table <literal>child</literal>? No, because it is
+ possible for some other user to delete the parent row from the
+ table <literal>parent</literal> in the meantime without you
+ being aware of it.
</para>
<para>
@@ -5175,40 +5176,59 @@
A shared mode lock prevents others from updating or deleting the
row we have read. Also, if the latest data belongs to a yet
uncommitted transaction of another client connection, we wait
- until that transaction commits. After we see that the preceding
- query returns the parent <literal>'Jones'</literal>, we can
- safely add the child record to the <literal>child</literal>
- table and commit our transaction.
+ until that transaction commits. After we see that the
+ <literal>LOCK IN SHARE MODE</literal> query returns the parent
+ <literal>'Jones'</literal>, we can safely add the child record
+ to the <literal>child</literal> table and commit our
+ transaction.
</para>
<para>
Let us look at another example: We have an integer counter field
in a table <literal>child_codes</literal> that we use to assign
a unique identifier to each child added to table
- <literal>child</literal>. Obviously, using a consistent read or
- a shared mode read to read the present value of the counter is
- not a good idea because two users of the database may then see
- the same value for the counter, and a duplicate-key error occurs
- if two users attempt to add children with the same identifier to
- the table.
+ <literal>child</literal>. Using a consistent read or a shared
+ mode read to read the present value of the counter is not a good
+ idea because two users of the database may then see the same
+ value for the counter, and a duplicate-key error occurs if two
+ users attempt to add children with the same identifier to the
+ table.
</para>
<para>
Here, <literal>LOCK IN SHARE MODE</literal> is not a good
solution because if two users read the counter at the same time,
- at least one of them ends up in deadlock when attempting to
+ at least one of them ends up in deadlock when it attempts to
update the counter.
</para>
<para>
- In this case, there are two good ways to implement the reading
- and incrementing of the counter: (1) update the counter first by
- incrementing it by 1 and only after that read it, or (2) read
- the counter first with a lock mode <literal>FOR
- UPDATE</literal>, and increment after that. The latter approach
- can be implemented as follows:
+ In this case, there are two good ways to implement reading and
+ incrementing the counter:
</para>
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Update the counter first by incrementing it by 1 and read it
+ only after that.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Read the counter first with a lock mode of <literal>FOR
+ UPDATE</literal>, and increment the counter after that.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ The latter approach can be implemented as follows:
+ </para>
+
<programlisting>
SELECT counter_field FROM child_codes FOR UPDATE;
UPDATE child_codes SET counter_field = counter_field + 1;
Modified: trunk/refman-6.0/se-innodb-core.xml
===================================================================
--- trunk/refman-6.0/se-innodb-core.xml 2008-11-07 19:17:08 UTC (rev 12339)
+++ trunk/refman-6.0/se-innodb-core.xml 2008-11-07 19:36:45 UTC (rev 12340)
Changed blocks: 2, Lines Added: 47, Lines Deleted: 27; 5068 bytes
@@ -5010,20 +5010,21 @@
<para>
In some circumstances, a consistent read is not convenient. For
- example, you might want to add a new row into your table
- <literal>child</literal>, and make sure that the child has a
- parent in table <literal>parent</literal>. The following example
- shows how to implement referential integrity in your application
- code.
+ example, you might want to insert a new row into your table
+ <literal>child</literal>, and make sure that the child row has a
+ parent row in table <literal>parent</literal>. The following
+ example describes how to implement referential integrity in your
+ application code.
</para>
<para>
Suppose that you use a consistent read to read the table
- <literal>parent</literal> and indeed see the parent of the child
- in the table. Can you safely add the child row to table
- <literal>child</literal>? No, because it may happen that
- meanwhile some other user deletes the parent row from the table
- <literal>parent</literal> without you being aware of it.
+ <literal>parent</literal> and indeed see the parent row of the
+ to-be-inserted child row in the table. Can you safely insert the
+ child row to table <literal>child</literal>? No, because it is
+ possible for some other user to delete the parent row from the
+ table <literal>parent</literal> in the meantime without you
+ being aware of it.
</para>
<para>
@@ -5042,40 +5043,59 @@
A shared mode lock prevents others from updating or deleting the
row we have read. Also, if the latest data belongs to a yet
uncommitted transaction of another client connection, we wait
- until that transaction commits. After we see that the preceding
- query returns the parent <literal>'Jones'</literal>, we can
- safely add the child record to the <literal>child</literal>
- table and commit our transaction.
+ until that transaction commits. After we see that the
+ <literal>LOCK IN SHARE MODE</literal> query returns the parent
+ <literal>'Jones'</literal>, we can safely add the child record
+ to the <literal>child</literal> table and commit our
+ transaction.
</para>
<para>
Let us look at another example: We have an integer counter field
in a table <literal>child_codes</literal> that we use to assign
a unique identifier to each child added to table
- <literal>child</literal>. Obviously, using a consistent read or
- a shared mode read to read the present value of the counter is
- not a good idea because two users of the database may then see
- the same value for the counter, and a duplicate-key error occurs
- if two users attempt to add children with the same identifier to
- the table.
+ <literal>child</literal>. Using a consistent read or a shared
+ mode read to read the present value of the counter is not a good
+ idea because two users of the database may then see the same
+ value for the counter, and a duplicate-key error occurs if two
+ users attempt to add children with the same identifier to the
+ table.
</para>
<para>
Here, <literal>LOCK IN SHARE MODE</literal> is not a good
solution because if two users read the counter at the same time,
- at least one of them ends up in deadlock when attempting to
+ at least one of them ends up in deadlock when it attempts to
update the counter.
</para>
<para>
- In this case, there are two good ways to implement the reading
- and incrementing of the counter: (1) update the counter first by
- incrementing it by 1 and only after that read it, or (2) read
- the counter first with a lock mode <literal>FOR
- UPDATE</literal>, and increment after that. The latter approach
- can be implemented as follows:
+ In this case, there are two good ways to implement reading and
+ incrementing the counter:
</para>
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Update the counter first by incrementing it by 1 and read it
+ only after that.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Read the counter first with a lock mode of <literal>FOR
+ UPDATE</literal>, and increment the counter after that.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ The latter approach can be implemented as follows:
+ </para>
+
<programlisting>
SELECT counter_field FROM child_codes FOR UPDATE;
UPDATE child_codes SET counter_field = counter_field + 1;
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r12340 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-6.0 | paul.dubois | 7 Nov |
