bk commit - mysqldoc@docsrva tree (paul:1.3583)

[paul]

Below is the list of changes that have just been committed into a local
mysqldoc repository of paul. When paul does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Installing_source_tree.html

ChangeSet
  1.3583 05/09/16 11:51:10 paul@stripped +4 -0
  Clarify effect of rollback due to deadlock/lock
  timeout.

  refman/innodb.xml
    1.42 05/09/16 11:51:08 paul@stripped +18 -5
    Clarify effect of rollback due to deadlock/lock
    timeout.

  refman-5.1/innodb.xml
    1.27 05/09/16 11:51:08 paul@stripped +12 -0
    Sync.

  refman-5.0/innodb.xml
    1.28 05/09/16 11:51:08 paul@stripped +12 -0
    Sync.

  refman-4.1/innodb.xml
    1.34 05/09/16 11:51:07 paul@stripped +12 -0
    Sync.

# This is a BitKeeper patch.  What follows are the unified diffs for the
# set of deltas contained in the patch.  The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User:	paul
# Host:	frost.snake.net
# Root:	/Users/paul/bk/mysqldoc

--- 1.26/refman-5.1/innodb.xml	2005-09-15 13:24:19 -05:00
+++ 1.27/refman-5.1/innodb.xml	2005-09-16 11:51:08 -05:00
@@ -5664,6 +5664,18 @@
           <literal>InnoDB</literal> rolls back only the most recent SQL
           statement.
         </para>
+
+        <para>
+          When a transaction rollback occurs due to a deadlock or lock
+          wait timeout, it cancels the effect of the statements in the
+          transaction. But if the transaction was begun with a
+          <literal>START TRANSACTION</literal> or
+          <literal>BEGIN</literal> statement, it does not cancel that
+          statement. Further SQL statements become part of the
+          transaction until the occurrence of <literal>COMMIT</literal>,
+          <literal>ROLLBACK</literal>, or some SQL statement that causes
+          an implicit commit.
+        </para>
       </listitem>
 
       <listitem>

--- 1.33/refman-4.1/innodb.xml	2005-09-16 08:27:40 -05:00
+++ 1.34/refman-4.1/innodb.xml	2005-09-16 11:51:07 -05:00
@@ -5795,6 +5795,18 @@
           A transaction deadlock or a timeout in a lock wait causes
           <literal>InnoDB</literal> to roll back the whole transaction.
         </para>
+
+        <para>
+          When a transaction rollback occurs due to a deadlock or lock
+          wait timeout, it cancels the effect of the statements in the
+          transaction. But if the transaction was begun with a
+          <literal>START TRANSACTION</literal> or
+          <literal>BEGIN</literal> statement, it does not cancel that
+          statement. Further SQL statements become part of the
+          transaction until the occurrence of <literal>COMMIT</literal>,
+          <literal>ROLLBACK</literal>, or some SQL statement that causes
+          an implicit commit.
+        </para>
       </listitem>
 
       <listitem>

--- 1.41/refman/innodb.xml	2005-09-16 08:27:40 -05:00
+++ 1.42/refman/innodb.xml	2005-09-16 11:51:08 -05:00
@@ -2290,11 +2290,12 @@
         <literal>UNIQUE</literal> and <literal>FOREIGN KEY</literal>
         constraints row-by-row. According to the SQL standard, the
         default behavior should be deferred checking, that is,
-        constraints are only checked after the <emphasis
-        role="bold">whole SQL statement</emphasis> has been processed.
-        Until InnoDB implements deferred constraint checking, some
-        things will be impossible, such as deleting a record that
-        refers to itself via a foreign key.
+        constraints are only checked after the
+        <emphasis
+        role="bold">whole SQL statement</emphasis> has
+        been processed. Until InnoDB implements deferred constraint
+        checking, some things will be impossible, such as deleting a
+        record that refers to itself via a foreign key.
       </para>
 
       <para>
@@ -5959,6 +5960,18 @@
           transaction before MySQL 5.0.13; as of 5.0.13,
           <literal>InnoDB</literal> rolls back only the most recent SQL
           statement.
+        </para>
+
+        <para>
+          When a transaction rollback occurs due to a deadlock or lock
+          wait timeout, it cancels the effect of the statements in the
+          transaction. But if the transaction was begun with a
+          <literal>START TRANSACTION</literal> or
+          <literal>BEGIN</literal> statement, it does not cancel that
+          statement. Further SQL statements become part of the
+          transaction until the occurrence of <literal>COMMIT</literal>,
+          <literal>ROLLBACK</literal>, or some SQL statement that causes
+          an implicit commit.
         </para>
       </listitem>
 

--- 1.27/refman-5.0/innodb.xml	2005-09-16 08:27:40 -05:00
+++ 1.28/refman-5.0/innodb.xml	2005-09-16 11:51:08 -05:00
@@ -5702,6 +5702,18 @@
           <literal>InnoDB</literal> rolls back only the most recent SQL
           statement.
         </para>
+
+        <para>
+          When a transaction rollback occurs due to a deadlock or lock
+          wait timeout, it cancels the effect of the statements in the
+          transaction. But if the transaction was begun with a
+          <literal>START TRANSACTION</literal> or
+          <literal>BEGIN</literal> statement, it does not cancel that
+          statement. Further SQL statements become part of the
+          transaction until the occurrence of <literal>COMMIT</literal>,
+          <literal>ROLLBACK</literal>, or some SQL statement that causes
+          an implicit commit.
+        </para>
       </listitem>
 
       <listitem>