Author: paul
Date: 2008-11-07 20:15:11 +0100 (Fri, 07 Nov 2008)
New Revision: 12338
Log:
r35422@frost: paul | 2008-11-07 13:03:02 -0500
Reformat
Modified:
trunk/dynamic-docs/changelog/connector-j.xml
trunk/dynamic-docs/changelog/mysqld.xml
trunk/refman-4.1/apis-c.xml
trunk/refman-4.1/dba-core.xml
trunk/refman-4.1/errors-problems.xml
trunk/refman-4.1/functions-core.xml
trunk/refman-4.1/introduction.xml
trunk/refman-4.1/mysql-cluster-faq.xml
trunk/refman-4.1/mysql-cluster-limitations.xml
trunk/refman-4.1/news-3.23.xml
trunk/refman-4.1/news-4.0.xml
trunk/refman-4.1/optimization.xml
trunk/refman-4.1/programs-client.xml
trunk/refman-4.1/replication.xml
trunk/refman-4.1/se-innodb-core.xml
trunk/refman-4.1/sql-syntax-transactions.xml
trunk/refman-4.1/storage-engines.xml
trunk/refman-5.0/apis-c.xml
trunk/refman-5.0/dba-core.xml
trunk/refman-5.0/errors-problems.xml
trunk/refman-5.0/faqs.xml
trunk/refman-5.0/functions-core.xml
trunk/refman-5.0/introduction.xml
trunk/refman-5.0/mysql-cluster-limitations.xml
trunk/refman-5.0/optimization.xml
trunk/refman-5.0/programs-client-core.xml
trunk/refman-5.0/replication-configuration.xml
trunk/refman-5.0/replication-notes.xml
trunk/refman-5.0/se-bdb-core.xml
trunk/refman-5.0/se-innodb-core.xml
trunk/refman-5.0/sql-syntax-data-definition.xml
trunk/refman-5.0/sql-syntax-transactions.xml
trunk/refman-5.0/storage-engines.xml
trunk/refman-5.0/stored-programs-views.xml
trunk/refman-5.0/triggers.xml
trunk/refman-5.1-maria/se-maria-core.xml
trunk/refman-5.1-maria/sql-syntax-server-administration.xml
trunk/refman-5.1-maria/storage-engines.xml
trunk/refman-5.1/apis-c.xml
trunk/refman-5.1/dba-core.xml
trunk/refman-5.1/errors-problems-core.xml
trunk/refman-5.1/functions-core.xml
trunk/refman-5.1/introduction.xml
trunk/refman-5.1/mysql-cluster-limitations.xml
trunk/refman-5.1/optimization.xml
trunk/refman-5.1/programs-client-core.xml
trunk/refman-5.1/replication-configuration-core.xml
trunk/refman-5.1/replication-notes.xml
trunk/refman-5.1/se-innodb-core.xml
trunk/refman-5.1/sql-syntax-data-definition.xml
trunk/refman-5.1/sql-syntax-transactions.xml
trunk/refman-5.1/storage-engines.xml
trunk/refman-5.1/stored-programs-views.xml
trunk/refman-5.1/triggers.xml
trunk/refman-6.0/apis-c.xml
trunk/refman-6.0/dba-core.xml
trunk/refman-6.0/errors-problems.xml
trunk/refman-6.0/functions-core.xml
trunk/refman-6.0/introduction.xml
trunk/refman-6.0/optimization.xml
trunk/refman-6.0/programs-client-core.xml
trunk/refman-6.0/replication-configuration-core.xml
trunk/refman-6.0/replication-notes.xml
trunk/refman-6.0/se-falcon-core.xml
trunk/refman-6.0/se-innodb-core.xml
trunk/refman-6.0/sql-syntax-data-definition.xml
trunk/refman-6.0/sql-syntax-transactions.xml
trunk/refman-6.0/storage-engines.xml
trunk/refman-6.0/stored-programs-views.xml
trunk/refman-6.0/triggers.xml
trunk/refman-common/news-innodb.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:35421
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:35422
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:34100
Modified: trunk/dynamic-docs/changelog/connector-j.xml
===================================================================
--- trunk/dynamic-docs/changelog/connector-j.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/dynamic-docs/changelog/connector-j.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 2, Lines Added: 7, Lines Deleted: 6; 1626 bytes
@@ -5146,9 +5146,9 @@
property
<literal>includeInnodbStatusInDeadlockExceptions</literal> to
<literal>true</literal> will cause the driver to append the
- output of <literal role="stmt" condition="show-engine">SHOW ENGINE INNODB STATUS</literal> to
- deadlock-related exceptions, which will enumerate the current
- locks held inside InnoDB.
+ output of <literal role="stmt" condition="show-engine">SHOW
+ ENGINE INNODB STATUS</literal> to deadlock-related exceptions,
+ which will enumerate the current locks held inside InnoDB.
</para>
</message>
@@ -16595,9 +16595,10 @@
Implementation of <literal>Statement.cancel()</literal> and
<literal>Statement.setQueryTimeout()</literal>. Both require
MySQL-5.0.0 or newer server, require a separate connection to
- issue the <literal role="stmt" condition="kill">KILL QUERY</literal> statement, and in the
- case of <literal>setQueryTimeout()</literal> creates an
- additional thread to handle the timeout functionality.
+ issue the <literal role="stmt" condition="kill">KILL
+ QUERY</literal> statement, and in the case of
+ <literal>setQueryTimeout()</literal> creates an additional
+ thread to handle the timeout functionality.
</para>
<para>
Modified: trunk/dynamic-docs/changelog/mysqld.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/dynamic-docs/changelog/mysqld.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 2, Lines Added: 4, Lines Deleted: 2; 1308 bytes
@@ -66220,7 +66220,8 @@
<message>
<para>
- The server failed to disallow <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal>
+ The server failed to disallow
+ <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal>
in stored functions and triggers. It is allowed to change the
value of <literal>AUTOCOMMIT</literal> in stored procedures, but
a runtime error might occur if the procedure is invoked from a
@@ -76228,7 +76229,8 @@
<literal role="stmt" condition="commit">ROLLBACK</literal>
statements support <literal>AND [NO] CHAIN</literal> and
<literal>RELEASE</literal> clauses. There is a new
- <literal role="stmt" condition="commit">RELEASE SAVEPOINT</literal> statement. The
+ <literal role="stmt" condition="commit">RELEASE
+ SAVEPOINT</literal> statement. The
<literal>completion_type</literal> system variable was added for
setting the global and session default completion type.
</para>
Modified: trunk/refman-4.1/apis-c.xml
===================================================================
--- trunk/refman-4.1/apis-c.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-4.1/apis-c.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 9, Lines Deleted: 8; 1557 bytes
@@ -1699,14 +1699,15 @@
Starting from MySQL 4.0.6, this command resets the state as if
one had done a new connect. (See
<xref linkend="auto-reconnect"/>.) It always performs a
- <literal role="stmt" condition="commit">ROLLBACK</literal> of any active transactions, closes
- and drops all temporary tables, and unlocks all locked tables.
- Session system variables are reset to the values of the
- corresponding global system variables. Prepared statements are
- released and <literal role="stmt">HANDLER</literal> variables
- are closed. Locks acquired with
- <literal role="func">GET_LOCK()</literal> are released. These
- effects occur even if the user didn't change.
+ <literal role="stmt" condition="commit">ROLLBACK</literal> of
+ any active transactions, closes and drops all temporary tables,
+ and unlocks all locked tables. Session system variables are
+ reset to the values of the corresponding global system
+ variables. Prepared statements are released and
+ <literal role="stmt">HANDLER</literal> variables are closed.
+ Locks acquired with <literal role="func">GET_LOCK()</literal>
+ are released. These effects occur even if the user didn't
+ change.
</para>
<para>
Modified: trunk/refman-4.1/dba-core.xml
===================================================================
--- trunk/refman-4.1/dba-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-4.1/dba-core.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 5, Lines Added: 33, Lines Deleted: 29; 5865 bytes
@@ -6225,15 +6225,18 @@
<para>
Set the autocommit mode. If set to 1, all changes to a table
take effect immediately. If set to 0 you have to use
- <literal role="stmt">COMMIT</literal> to accept a transaction or
- <literal role="stmt" condition="commit">ROLLBACK</literal> to cancel it. By default, client
- connections begin with <literal>AUTOCOMMIT</literal> set to
- 1. If you change <literal>AUTOCOMMIT</literal> mode from 0
- to 1, MySQL performs an automatic <literal role="stmt">COMMIT</literal>
+ <literal role="stmt">COMMIT</literal> to accept a
+ transaction or
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ to cancel it. By default, client connections begin with
+ <literal>AUTOCOMMIT</literal> set to 1. If you change
+ <literal>AUTOCOMMIT</literal> mode from 0 to 1, MySQL
+ performs an automatic <literal role="stmt">COMMIT</literal>
of any open transaction. Another way to begin a transaction
- is to use a <literal role="stmt" condition="commit">START TRANSACTION</literal> or
- <literal role="stmt" condition="commit">BEGIN</literal> statement. See
- <xref linkend="commit"/>.
+ is to use a <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> or
+ <literal role="stmt" condition="commit">BEGIN</literal>
+ statement. See <xref linkend="commit"/>.
</para>
</listitem>
@@ -7717,8 +7720,8 @@
</para>
<para>
- The number of internal <literal role="stmt">COMMIT</literal> statements.
- This variable was added in MySQL 4.0.2.
+ The number of internal <literal role="stmt">COMMIT</literal>
+ statements. This variable was added in MySQL 4.0.2.
</para>
</listitem>
@@ -7818,7 +7821,8 @@
</para>
<para>
- The number of internal <literal role="stmt" condition="commit">ROLLBACK</literal>
+ The number of internal
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
statements. This variable was added in MySQL 4.0.2.
</para>
</listitem>
@@ -10613,24 +10617,24 @@
<literal role="stmt">INSERT</literal>) that change transactional
tables such as <literal>BDB</literal> or
<literal>InnoDB</literal> tables are cached until a
- <literal role="stmt">COMMIT</literal> statement is received by the server.
- At that point, <command>mysqld</command> writes the entire
- transaction to the binary log before the
- <literal role="stmt">COMMIT</literal> is executed. When the thread that
- handles the transaction starts, it allocates a buffer of
- <literal>binlog_cache_size</literal> to buffer statements. If a
- statement is bigger than this, the thread opens a temporary file
- to store the transaction. The temporary file is deleted when the
- thread ends.
+ <literal role="stmt">COMMIT</literal> statement is received by
+ the server. At that point, <command>mysqld</command> writes the
+ entire transaction to the binary log before the
+ <literal role="stmt">COMMIT</literal> is executed. When the
+ thread that handles the transaction starts, it allocates a
+ buffer of <literal>binlog_cache_size</literal> to buffer
+ statements. If a statement is bigger than this, the thread opens
+ a temporary file to store the transaction. The temporary file is
+ deleted when the thread ends.
</para>
<para>
Modifications to non-transactional tables cannot be rolled back.
If a transaction that is rolled back includes modifications to
non-transactional tables, the entire transaction is logged with
- a <literal role="stmt" condition="commit">ROLLBACK</literal> statement at the end to ensure
- that the modifications to those tables are replicated. This is
- true as of MySQL 4.0.15.
+ a <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement at the end to ensure that the modifications to those
+ tables are replicated. This is true as of MySQL 4.0.15.
</para>
<para>
@@ -10682,12 +10686,12 @@
chance of an inconsistency between the table content and binary
log content in case of a crash. For example, if you are using
<literal>InnoDB</literal> tables and the MySQL server processes
- a <literal role="stmt">COMMIT</literal> statement, it writes the whole
- transaction to the binary log and then commits this transaction
- into <literal>InnoDB</literal>. If the server crashes between
- those two operations, the transaction is rolled back by
- <literal>InnoDB</literal> at restart but still exists in the
- binary log. This problem can be solved with the
+ a <literal role="stmt">COMMIT</literal> statement, it writes the
+ whole transaction to the binary log and then commits this
+ transaction into <literal>InnoDB</literal>. If the server
+ crashes between those two operations, the transaction is rolled
+ back by <literal>InnoDB</literal> at restart but still exists in
+ the binary log. This problem can be solved with the
<option>--innodb-safe-binlog</option> option (available starting
from MySQL 4.1.3), which adds consistency between the content of
<literal>InnoDB</literal> tables and the binary log.
Modified: trunk/refman-4.1/errors-problems.xml
===================================================================
--- trunk/refman-4.1/errors-problems.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-4.1/errors-problems.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 3, Lines Added: 8, Lines Deleted: 7; 1715 bytes
@@ -4378,9 +4378,9 @@
<para>
If you receive the following message when trying to perform a
- <literal role="stmt" condition="commit">ROLLBACK</literal>, it means that one or more of the
- tables you used in the transaction do not support
- transactions:
+ <literal role="stmt" condition="commit">ROLLBACK</literal>, it
+ means that one or more of the tables you used in the
+ transaction do not support transactions:
</para>
<programlisting>
@@ -4389,7 +4389,8 @@
<para>
These non-transactional tables are not affected by the
- <literal role="stmt" condition="commit">ROLLBACK</literal> statement.
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement.
</para>
<para>
@@ -5542,9 +5543,9 @@
<para>
<literal role="stmt" condition="flush">FLUSH TABLES WITH
READ LOCK</literal> does not block
- <literal role="stmt">COMMIT</literal> if the server is running without
- binary logging, which may cause a problem (of consistency
- between tables) when doing a full backup.
+ <literal role="stmt">COMMIT</literal> if the server is
+ running without binary logging, which may cause a problem
+ (of consistency between tables) when doing a full backup.
</para>
</listitem>
Modified: trunk/refman-4.1/functions-core.xml
===================================================================
--- trunk/refman-4.1/functions-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-4.1/functions-core.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 6, Lines Deleted: 4; 1249 bytes
@@ -14998,10 +14998,12 @@
undefined. For transactional tables, if the statement is
rolled back due to an error, the value of
<literal role="func">LAST_INSERT_ID()</literal> is left
- undefined. For manual <literal role="stmt" condition="commit">ROLLBACK</literal>, the value
- of <literal role="func">LAST_INSERT_ID()</literal> is not
- restored to that before the transaction; it remains as it
- was at the point of the <literal role="stmt" condition="commit">ROLLBACK</literal>.
+ undefined. For manual
+ <literal role="stmt" condition="commit">ROLLBACK</literal>,
+ the value of <literal role="func">LAST_INSERT_ID()</literal>
+ is not restored to that before the transaction; it remains
+ as it was at the point of the
+ <literal role="stmt" condition="commit">ROLLBACK</literal>.
</para>
<remark role="help-description-end"/>
Modified: trunk/refman-4.1/introduction.xml
===================================================================
--- trunk/refman-4.1/introduction.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-4.1/introduction.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 3, Lines Added: 16, Lines Deleted: 14; 2769 bytes
@@ -2116,13 +2116,13 @@
<para>
If your applications are written in a way that is
dependent on being able to call
- <literal role="stmt" condition="commit">ROLLBACK</literal> rather than
- <literal role="stmt">COMMIT</literal> in critical situations,
- transactions are more convenient. Transactions also ensure
- that unfinished updates or corrupting activities are not
- committed to the database; the server is given the
- opportunity to do an automatic rollback and your database
- is saved.
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ rather than <literal role="stmt">COMMIT</literal> in
+ critical situations, transactions are more convenient.
+ Transactions also ensure that unfinished updates or
+ corrupting activities are not committed to the database;
+ the server is given the opportunity to do an automatic
+ rollback and your database is saved.
</para>
<para>
@@ -2219,8 +2219,9 @@
<listitem>
<para>
- To avoid using <literal role="stmt" condition="commit">ROLLBACK</literal>, you can employ
- the following strategy:
+ To avoid using
+ <literal role="stmt" condition="commit">ROLLBACK</literal>,
+ you can employ the following strategy:
</para>
<orderedlist>
@@ -2343,11 +2344,12 @@
</indexterm>
In many cases, users have wanted <literal role="stmt">LOCK
- TABLES</literal> or <literal role="stmt" condition="commit">ROLLBACK</literal> for the
- purpose of managing unique identifiers. This can be
- handled much more efficiently without locking or rolling
- back by using an <literal>AUTO_INCREMENT</literal> column
- and either the
+ TABLES</literal> or
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ for the purpose of managing unique identifiers. This can
+ be handled much more efficiently without locking or
+ rolling back by using an <literal>AUTO_INCREMENT</literal>
+ column and either the
<literal role="func">LAST_INSERT_ID()</literal> SQL
function or the
<literal role="cfunc">mysql_insert_id()</literal> C API
Modified: trunk/refman-4.1/mysql-cluster-faq.xml
===================================================================
--- trunk/refman-4.1/mysql-cluster-faq.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-4.1/mysql-cluster-faq.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 1; 734 bytes
@@ -1213,7 +1213,8 @@
supported. A failed insert due to a duplicate key or
similar error causes a transaction to abort; when this
occurs, you must issue an explicit
- <literal role="stmt" condition="commit">ROLLBACK</literal> and retry the transaction.
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ and retry the transaction.
</para>
</listitem>
Modified: trunk/refman-4.1/mysql-cluster-limitations.xml
===================================================================
--- trunk/refman-4.1/mysql-cluster-limitations.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-4.1/mysql-cluster-limitations.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 3, Lines Deleted: 2; 830 bytes
@@ -592,8 +592,9 @@
statements raise <errortext>ERROR 1296 (HY000): Got error
4350 'Transaction already aborted' from
NDBCLUSTER</errortext>. In such cases, you must issue an
- explicit <literal role="stmt" condition="commit">ROLLBACK</literal> and retry the entire
- transaction.
+ explicit
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ and retry the entire transaction.
</para>
</formalpara>
Modified: trunk/refman-4.1/news-3.23.xml
===================================================================
--- trunk/refman-4.1/news-3.23.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-4.1/news-3.23.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 4, Lines Added: 13, Lines Deleted: 8; 1992 bytes
@@ -1130,9 +1130,10 @@
<listitem>
<para>
- Wrap <literal role="stmt" condition="commit">BEGIN</literal>/<literal role="stmt">COMMIT</literal> around
- transaction in the binary log. This makes replication honor
- transactions.
+ Wrap
+ <literal role="stmt" condition="commit">BEGIN</literal>/<literal role="stmt">COMMIT</literal>
+ around transaction in the binary log. This makes replication
+ honor transactions.
</para>
</listitem>
@@ -4459,8 +4460,10 @@
<listitem>
<para>
- If you do a <literal role="stmt" condition="commit">ROLLBACK</literal> when you have updated
- a non-transactional table you get an error as a warning.
+ If you do a
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ when you have updated a non-transactional table you get an
+ error as a warning.
</para>
</listitem>
@@ -6219,7 +6222,8 @@
<listitem>
<para>
- Added the syntax <literal role="stmt" condition="commit">BEGIN WORK</literal> (the same as
+ Added the syntax <literal role="stmt" condition="commit">BEGIN
+ WORK</literal> (the same as
<literal role="stmt" condition="commit">BEGIN</literal>).
</para>
</listitem>
@@ -6394,8 +6398,9 @@
<listitem>
<para>
- Added <literal role="stmt" condition="commit">BEGIN</literal> statement to start a
- transaction in <literal>AUTOCOMMIT</literal> mode.
+ Added <literal role="stmt" condition="commit">BEGIN</literal>
+ statement to start a transaction in
+ <literal>AUTOCOMMIT</literal> mode.
</para>
</listitem>
Modified: trunk/refman-4.1/news-4.0.xml
===================================================================
--- trunk/refman-4.1/news-4.0.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-4.1/news-4.0.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 9, Lines Added: 35, Lines Deleted: 26; 6161 bytes
@@ -1560,7 +1560,8 @@
<para>
If a connection was interrupted by a network error and did a
rollback, the network error code got stored into the
- <literal role="stmt" condition="commit">BEGIN</literal> and <literal role="stmt" condition="commit">ROLLBACK</literal>
+ <literal role="stmt" condition="commit">BEGIN</literal> and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
binary log events; that caused superfluous slave stops. (Bug
#6522)
</para>
@@ -1568,8 +1569,9 @@
<listitem>
<para>
- A sequence of <literal role="stmt" condition="commit">BEGIN</literal> (or <literal>SET
- AUTOCOMMIT=0</literal>),
+ A sequence of
+ <literal role="stmt" condition="commit">BEGIN</literal> (or
+ <literal>SET AUTOCOMMIT=0</literal>),
<literal role="stmt" condition="flush">FLUSH TABLES WITH READ
LOCK</literal>, transactional update,
<literal role="stmt">COMMIT</literal>,
@@ -1757,10 +1759,10 @@
InnoDB: Fixed problem introduced in 4.0.21 where a connection
starting a transaction, doing updates, then
<literal role="stmt" condition="flush">FLUSH TABLES WITH READ
- LOCK</literal>, then <literal role="stmt">COMMIT</literal>, would cause
- replication slaves to stop (complaining about error 1223). Bug
- surfaced when using the InnoDB <literal>innobackup</literal>
- script. (Bug #5949)
+ LOCK</literal>, then <literal role="stmt">COMMIT</literal>,
+ would cause replication slaves to stop (complaining about
+ error 1223). Bug surfaced when using the InnoDB
+ <literal>innobackup</literal> script. (Bug #5949)
</para>
</listitem>
@@ -2199,10 +2201,11 @@
<listitem>
<para>
Made <literal role="stmt" condition="flush">FLUSH TABLES WITH
- READ LOCK</literal> block <literal role="stmt">COMMIT</literal> if server
- is running with binary logging; this ensures that the binary
- log position is trustable when doing a full backup of tables
- and the binary log. (Bug #4953)
+ READ LOCK</literal> block
+ <literal role="stmt">COMMIT</literal> if server is running
+ with binary logging; this ensures that the binary log position
+ is trustable when doing a full backup of tables and the binary
+ log. (Bug #4953)
</para>
</listitem>
@@ -4807,10 +4810,11 @@
<para>
When, in a transaction, <literal>INSERT ... SELECT</literal>
updated a non-transactional table, and
- <literal role="stmt" condition="commit">ROLLBACK</literal> was issued, no error was returned
- to the client. Now the client is warned that some changes
- could not be rolled back, as this was the case for normal
- <literal role="stmt">INSERT</literal>. (Bug #1113)
+ <literal role="stmt" condition="commit">ROLLBACK</literal> was
+ issued, no error was returned to the client. Now the client is
+ warned that some changes could not be rolled back, as this was
+ the case for normal <literal role="stmt">INSERT</literal>.
+ (Bug #1113)
</para>
</listitem>
@@ -6281,8 +6285,8 @@
<literal>Relay_Master_Log_File</literal> and
<literal>Exec_Master_Log_Pos</literal>) for the last executed
statement from the master, if this statement was the
- <literal role="stmt">COMMIT</literal> of a transaction. The master must be
- upgraded for that, not the slave. (Bug #52)
+ <literal role="stmt">COMMIT</literal> of a transaction. The
+ master must be upgraded for that, not the slave. (Bug #52)
</para>
</listitem>
@@ -6414,9 +6418,11 @@
<listitem>
<para>
- Added <literal role="stmt" condition="commit">START TRANSACTION</literal> (standard SQL
- syntax) as alias for <literal role="stmt" condition="commit">BEGIN</literal>. This is
- recommended to use instead of <literal role="stmt" condition="commit">BEGIN</literal> to
+ Added <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> (standard SQL syntax) as alias for
+ <literal role="stmt" condition="commit">BEGIN</literal>. This
+ is recommended to use instead of
+ <literal role="stmt" condition="commit">BEGIN</literal> to
start a transaction.
</para>
</listitem>
@@ -7193,8 +7199,9 @@
<para>
<literal role="cfunc">mysql_change_user()</literal> now resets
the connection to the state of a fresh connect (Ie,
- <literal role="stmt" condition="commit">ROLLBACK</literal> any active transaction, close all
- temporary tables, reset all user variables etc..)
+ <literal role="stmt" condition="commit">ROLLBACK</literal> any
+ active transaction, close all temporary tables, reset all user
+ variables etc..)
</para>
</listitem>
@@ -7516,10 +7523,12 @@
<para>
When transactions are enabled, all commands that update
temporary tables inside a <literal>BEGIN/COMMIT</literal> are
- now stored in the binary log on <literal role="stmt">COMMIT</literal> and
- not stored if one does <literal role="stmt" condition="commit">ROLLBACK</literal>. This fixes
- some problems with non-transactional temporary tables used
- inside transactions.
+ now stored in the binary log on
+ <literal role="stmt">COMMIT</literal> and not stored if one
+ does
+ <literal role="stmt" condition="commit">ROLLBACK</literal>.
+ This fixes some problems with non-transactional temporary
+ tables used inside transactions.
</para>
</listitem>
Modified: trunk/refman-4.1/optimization.xml
===================================================================
--- trunk/refman-4.1/optimization.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-4.1/optimization.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 1; 702 bytes
@@ -4192,7 +4192,8 @@
<para>
To obtain faster insertions for transactional tables, you
- should use <literal role="stmt" condition="commit">START TRANSACTION</literal> and
+ should use <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> and
<literal role="stmt">COMMIT</literal> instead of
<literal role="stmt">LOCK TABLES</literal>.
</para>
Modified: trunk/refman-4.1/programs-client.xml
===================================================================
--- trunk/refman-4.1/programs-client.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-4.1/programs-client.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 2, Lines Added: 11, Lines Deleted: 9; 1782 bytes
@@ -6180,8 +6180,8 @@
<para>
Enclose the <literal role="stmt">INSERT</literal> statements
for each dumped table within <literal>SET
- AUTOCOMMIT=0</literal> and <literal role="stmt">COMMIT</literal>
- statements.
+ AUTOCOMMIT=0</literal> and
+ <literal role="stmt">COMMIT</literal> statements.
</para>
</listitem>
@@ -6533,13 +6533,15 @@
</para>
<para>
- This option issues a <literal role="stmt" condition="commit">BEGIN</literal> SQL statement
- before dumping data from the server. It is useful only with
- transactional tables such as <literal>InnoDB</literal> and
- <literal>BDB</literal>, because then it dumps the consistent
- state of the database at the time when
- <literal role="stmt" condition="commit">BEGIN</literal> was issued without blocking any
- applications.
+ This option issues a
+ <literal role="stmt" condition="commit">BEGIN</literal> SQL
+ statement before dumping data from the server. It is useful
+ only with transactional tables such as
+ <literal>InnoDB</literal> and <literal>BDB</literal>,
+ because then it dumps the consistent state of the database
+ at the time when
+ <literal role="stmt" condition="commit">BEGIN</literal> was
+ issued without blocking any applications.
</para>
<para>
Modified: trunk/refman-4.1/replication.xml
===================================================================
--- trunk/refman-4.1/replication.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-4.1/replication.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 4, Lines Added: 23, Lines Deleted: 18; 3992 bytes
@@ -1747,9 +1747,11 @@
<listitem>
<para>
There are problems if the slave is stopped in the middle
- of a <literal role="stmt" condition="commit">BEGIN</literal>/<literal role="stmt">COMMIT</literal>
+ of a
+ <literal role="stmt" condition="commit">BEGIN</literal>/<literal role="stmt">COMMIT</literal>
block because the slave restarts at the beginning of the
- <literal role="stmt" condition="commit">BEGIN</literal> block.
+ <literal role="stmt" condition="commit">BEGIN</literal>
+ block.
</para>
</listitem>
@@ -2137,11 +2139,12 @@
<para>
If you update transactional tables from non-transactional
tables inside a
- <literal role="stmt" condition="commit">BEGIN</literal>/<literal role="stmt">COMMIT</literal> sequence,
- updates to the binary log may be out of synchrony with table
- states if the non-transactional table is updated before the
- transaction commits. This occurs because the transaction is
- written to the binary log only when it is committed.
+ <literal role="stmt" condition="commit">BEGIN</literal>/<literal role="stmt">COMMIT</literal>
+ sequence, updates to the binary log may be out of synchrony
+ with table states if the non-transactional table is updated
+ before the transaction commits. This occurs because the
+ transaction is written to the binary log only when it is
+ committed.
</para>
<caution>
@@ -2157,12 +2160,13 @@
Before version 4.0.15, any update to a non-transactional table
is written to the binary log at once when the update is made,
whereas transactional updates are written on
- <literal role="stmt">COMMIT</literal> or not written at all if you use
- <literal role="stmt" condition="commit">ROLLBACK</literal>. You must take this into account
- when updating both transactional tables and non-transactional
- tables within the same transaction. (This is true not only for
- replication, but also if you are using binary logging for
- backups.)
+ <literal role="stmt">COMMIT</literal> or not written at all if
+ you use
+ <literal role="stmt" condition="commit">ROLLBACK</literal>.
+ You must take this into account when updating both
+ transactional tables and non-transactional tables within the
+ same transaction. (This is true not only for replication, but
+ also if you are using binary logging for backups.)
</para>
<para>
@@ -2171,11 +2175,12 @@
non-transactional tables, which solves the problems (order of
statements is good in the binary log, and all needed
statements are written to the binary log even in case of
- <literal role="stmt" condition="commit">ROLLBACK</literal>). The problem that remains is that
- when a second connection updates the non-transactional table
- while the first connection's transaction is not finished yet,
- incorrect ordering can still occur because the second
- connection's update is written immediately after it is done.
+ <literal role="stmt" condition="commit">ROLLBACK</literal>).
+ The problem that remains is that when a second connection
+ updates the non-transactional table while the first
+ connection's transaction is not finished yet, incorrect
+ ordering can still occur because the second connection's
+ update is written immediately after it is done.
</para>
</listitem>
Modified: trunk/refman-4.1/se-innodb-core.xml
===================================================================
--- trunk/refman-4.1/se-innodb-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-4.1/se-innodb-core.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 10, Lines Added: 53, Lines Deleted: 37; 8915 bytes
@@ -2101,13 +2101,17 @@
SQL statement as you execute it. To use multiple-statement
transactions, you can switch autocommit off with the SQL
statement <literal>SET AUTOCOMMIT = 0</literal> and end each
- transaction with either <literal role="stmt">COMMIT</literal> and
- <literal role="stmt" condition="commit">ROLLBACK</literal>. If you want to leave autocommit on,
- you can begin your transactions within <literal role="stmt" condition="commit">START
+ transaction with either <literal role="stmt">COMMIT</literal>
+ and <literal role="stmt" condition="commit">ROLLBACK</literal>.
+ If you want to leave autocommit on, you can begin your
+ transactions within
+ <literal role="stmt" condition="commit">START
TRANSACTION</literal> and end them with
- <literal role="stmt">COMMIT</literal> or <literal role="stmt" condition="commit">ROLLBACK</literal>. Before
- MySQL 4.0.11, you have to use the keyword
- <literal role="stmt" condition="commit">BEGIN</literal> instead of <literal role="stmt" condition="commit">START
+ <literal role="stmt">COMMIT</literal> or
+ <literal role="stmt" condition="commit">ROLLBACK</literal>.
+ Before MySQL 4.0.11, you have to use the keyword
+ <literal role="stmt" condition="commit">BEGIN</literal> instead
+ of <literal role="stmt" condition="commit">START
TRANSACTION</literal>. The following example shows two
transactions. The first is committed and the second is rolled
back.
@@ -2144,9 +2148,9 @@
<para>
In APIs such as PHP, Perl DBI, JDBC, ODBC, or the standard C
call interface of MySQL, you can send transaction control
- statements such as <literal role="stmt">COMMIT</literal> to the MySQL server
- as strings just like any other SQL statements such as
- <literal role="stmt">SELECT</literal> or
+ statements such as <literal role="stmt">COMMIT</literal> to the
+ MySQL server as strings just like any other SQL statements such
+ as <literal role="stmt">SELECT</literal> or
<literal role="stmt">INSERT</literal>. Some APIs also offer
separate special transaction commit and rollback functions or
methods.
@@ -4150,14 +4154,17 @@
<para>
If autocommit mode is disabled within a session with
<literal>SET AUTOCOMMIT = 0</literal>, the session always has a
- transaction open. An SQL <literal role="stmt">COMMIT</literal> or
- <literal role="stmt" condition="commit">ROLLBACK</literal> statement ends the current
- transaction and a new one starts. A <literal role="stmt">COMMIT</literal>
- means that the changes made in the current transaction are made
- permanent and become visible to other sessions. A
- <literal role="stmt" condition="commit">ROLLBACK</literal> statement, on the other hand,
- cancels all modifications made by the current transaction. Both
- <literal role="stmt">COMMIT</literal> and <literal role="stmt" condition="commit">ROLLBACK</literal>
+ transaction open. An SQL <literal role="stmt">COMMIT</literal>
+ or <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement ends the current transaction and a new one starts. A
+ <literal role="stmt">COMMIT</literal> means that the changes
+ made in the current transaction are made permanent and become
+ visible to other sessions. A
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement, on the other hand, cancels all modifications made by
+ the current transaction. Both
+ <literal role="stmt">COMMIT</literal> and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
release all <literal>InnoDB</literal> locks that were set during
the current transaction.
</para>
@@ -4165,9 +4172,11 @@
<para>
If the session has autocommit enabled, a multiple-statement
transaction can be performed by starting it with an explicit
- <literal role="stmt" condition="commit">START TRANSACTION</literal> or
-<literal role="stmt" condition="commit">BEGIN</literal>
- statement and ending it with <literal role="stmt">COMMIT</literal> or
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> or
+ <literal role="stmt" condition="commit">BEGIN</literal>
+ statement and ending it with
+ <literal role="stmt">COMMIT</literal> or
<literal role="stmt" condition="commit">ROLLBACK</literal>.
</para>
@@ -4464,7 +4473,8 @@
<para>
Locking of rows for update using <literal>SELECT FOR
UPDATE</literal> only applies when autocommit is disabled
- (either by beginning transaction with <literal role="stmt" condition="commit">START
+ (either by beginning transaction with
+ <literal role="stmt" condition="commit">START
TRANSACTION</literal> or by setting
<literal>AUTOCOMMIT</literal> to 0. If autocommit is enabled,
the rows matching the specification are not locked.
@@ -4859,8 +4869,9 @@
<para>
For details about which statements implicitly end a transaction,
- as if you had done a <literal role="stmt">COMMIT</literal> before executing
- the statement, see <xref linkend="implicit-commit"/>.
+ as if you had done a <literal role="stmt">COMMIT</literal>
+ before executing the statement, see
+ <xref linkend="implicit-commit"/>.
</para>
</section>
@@ -5211,8 +5222,9 @@
that MySQL does not have autocommit mode enabled because that
requires a log flush to disk for every insert. To disable
autocommit during your import operation, surround it with
- <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal> and
- <literal role="stmt">COMMIT</literal> statements:
+ <literal role="stmt" condition="commit">SET
+ AUTOCOMMIT</literal> and <literal role="stmt">COMMIT</literal>
+ statements:
</para>
<programlisting>
@@ -5225,8 +5237,10 @@
If you use the <command>mysqldump</command> option
<option>--opt</option>, you get dump files that are fast to
import into an <literal>InnoDB</literal> table, even without
- wrapping them with the <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal> and
- <literal role="stmt">COMMIT</literal> statements.
+ wrapping them with the
+ <literal role="stmt" condition="commit">SET
+ AUTOCOMMIT</literal> and <literal role="stmt">COMMIT</literal>
+ statements.
</para>
</listitem>
@@ -6350,12 +6364,14 @@
When a transaction rollback occurs due to a deadlock or lock
wait timeout, it cancels the effect of the statements within
the transaction. But if the start-transaction statement was
- <literal role="stmt" condition="commit">START TRANSACTION</literal> or
- <literal role="stmt" condition="commit">BEGIN</literal> statement, rollback does not cancel
- that statement. Further SQL statements become part of the
- transaction until the occurrence of <literal role="stmt">COMMIT</literal>,
- <literal role="stmt" condition="commit">ROLLBACK</literal>, or some SQL statement that causes
- an implicit commit.
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> or
+ <literal role="stmt" condition="commit">BEGIN</literal>
+ statement, rollback does not cancel that statement. Further
+ SQL statements become part of the transaction until the
+ occurrence of <literal role="stmt">COMMIT</literal>,
+ <literal role="stmt" condition="commit">ROLLBACK</literal>, or
+ some SQL statement that causes an implicit commit.
</para>
</listitem>
@@ -6387,10 +6403,10 @@
<para>
During such implicit rollbacks, as well as during the explicit
- <literal role="stmt" condition="commit">ROLLBACK</literal> SQL statement,
- <literal role="stmt">SHOW PROCESSLIST</literal> displays "Rolling
- back" in the <literal>State</literal> column for the connection
- (starting from MySQL 4.1.8).
+ <literal role="stmt" condition="commit">ROLLBACK</literal> SQL
+ statement, <literal role="stmt">SHOW PROCESSLIST</literal>
+ displays "Rolling back" in the <literal>State</literal> column for
+ the connection (starting from MySQL 4.1.8).
</para>
<section id="innodb-error-codes">
Modified: trunk/refman-4.1/sql-syntax-transactions.xml
===================================================================
--- trunk/refman-4.1/sql-syntax-transactions.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-4.1/sql-syntax-transactions.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 21, Lines Added: 110, Lines Deleted: 74; 17655 bytes
@@ -11,14 +11,18 @@
<para>
MySQL supports local transactions (within a given client session)
- through statements such as <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal>,
- <literal role="stmt" condition="commit">START TRANSACTION</literal>, <literal role="stmt">COMMIT</literal>, and
- <literal role="stmt" condition="commit">ROLLBACK</literal>. See <xref linkend="commit"/>.
+ through statements such as
+ <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal>,
+ <literal role="stmt" condition="commit">START TRANSACTION</literal>,
+ <literal role="stmt">COMMIT</literal>, and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>. See
+ <xref linkend="commit"/>.
</para>
<section id="commit">
- <title><literal role="stmt" condition="commit">START TRANSACTION</literal>, <literal role="stmt">COMMIT</literal>, and
+ <title><literal role="stmt" condition="commit">START TRANSACTION</literal>,
+ <literal role="stmt">COMMIT</literal>, and
<literal role="stmt" condition="commit">ROLLBACK</literal> Syntax</title>
<indexterm>
@@ -56,13 +60,16 @@
<remark role="help-description-begin"/>
<para>
- The <literal role="stmt" condition="commit">START TRANSACTION</literal> or
- <literal role="stmt" condition="commit">BEGIN</literal> statement begins a new transaction.
- <literal role="stmt">COMMIT</literal> commits the current transaction, making
- its changes permanent. <literal role="stmt" condition="commit">ROLLBACK</literal> rolls back the
- current transaction, canceling its changes. The <literal role="stmt" condition="commit">SET
- AUTOCOMMIT</literal> statement disables or enables the default
- autocommit mode for the current session.
+ The <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> or
+ <literal role="stmt" condition="commit">BEGIN</literal> statement
+ begins a new transaction. <literal role="stmt">COMMIT</literal>
+ commits the current transaction, making its changes permanent.
+ <literal role="stmt" condition="commit">ROLLBACK</literal> rolls
+ back the current transaction, canceling its changes. The
+ <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal>
+ statement disables or enables the default autocommit mode for the
+ current session.
</para>
<para>
@@ -89,13 +96,15 @@
transaction-safe tables (such as those for
<literal>InnoDB</literal> or <literal>NDBCLUSTER</literal>) are
not made permanent immediately. You must use
- <literal role="stmt">COMMIT</literal> to store your changes to disk or
- <literal role="stmt" condition="commit">ROLLBACK</literal> to ignore the changes.
+ <literal role="stmt">COMMIT</literal> to store your changes to
+ disk or <literal role="stmt" condition="commit">ROLLBACK</literal>
+ to ignore the changes.
</para>
<para>
To disable autocommit mode for a single series of statements, use
- the <literal role="stmt" condition="commit">START TRANSACTION</literal> statement:
+ the <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> statement:
</para>
<remark role="help-description-end"/>
@@ -110,19 +119,25 @@
</programlisting>
<para>
- With <literal role="stmt" condition="commit">START TRANSACTION</literal>, autocommit remains
- disabled until you end the transaction with
- <literal role="stmt">COMMIT</literal> or <literal role="stmt" condition="commit">ROLLBACK</literal>. The
+ With <literal role="stmt" condition="commit">START
+ TRANSACTION</literal>, autocommit remains disabled until you end
+ the transaction with <literal role="stmt">COMMIT</literal> or
+ <literal role="stmt" condition="commit">ROLLBACK</literal>. The
autocommit mode then reverts to its previous state.
</para>
<para>
- <literal role="stmt" condition="commit">BEGIN</literal> and <literal role="stmt" condition="commit">BEGIN WORK</literal> are
- supported as aliases of <literal role="stmt" condition="commit">START TRANSACTION</literal> for
- initiating a transaction. <literal role="stmt" condition="commit">START TRANSACTION</literal> was
- added in MySQL 4.0.11. This is standard SQL syntax and is the
- recommended way to start an ad-hoc transaction.
- <literal role="stmt" condition="commit">BEGIN</literal> and <literal role="stmt" condition="commit">BEGIN WORK</literal> are
+ <literal role="stmt" condition="commit">BEGIN</literal> and
+ <literal role="stmt" condition="commit">BEGIN WORK</literal> are
+ supported as aliases of
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> for initiating a transaction.
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> was added in MySQL 4.0.11. This is standard
+ SQL syntax and is the recommended way to start an ad-hoc
+ transaction.
+ <literal role="stmt" condition="commit">BEGIN</literal> and
+ <literal role="stmt" condition="commit">BEGIN WORK</literal> are
available from MySQL 3.23.17 and 3.23.19, respectively.
</para>
@@ -131,9 +146,10 @@
Many APIs used for writing MySQL client applications (such as
JDBC) provide their own methods for starting transactions that
can (and sometimes should) be used instead of sending a
- <literal role="stmt" condition="commit">START TRANSACTION</literal> statement from the client.
- See <xref linkend="connectors-apis"/>, or the documentation for
- your API, for more information.
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> statement from the client. See
+ <xref linkend="connectors-apis"/>, or the documentation for your
+ API, for more information.
</para>
</important>
@@ -149,7 +165,8 @@
The <literal>WITH CONSISTENT SNAPSHOT</literal> clause starts a
consistent read for storage engines that are capable of it. This
applies only to <literal>InnoDB</literal>. The effect is the same
- as issuing a <literal role="stmt" condition="commit">START TRANSACTION</literal> followed by a
+ as issuing a <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> followed by a
<literal role="stmt">SELECT</literal> from any
<literal>InnoDB</literal> table. See
<xref linkend="innodb-consistent-read"/>. The <literal>WITH
@@ -213,8 +230,10 @@
<listitem>
<para>
- If you issue a <literal role="stmt" condition="commit">ROLLBACK</literal> statement after
- updating a non-transactional table within a transaction, an
+ If you issue a
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement after updating a non-transactional table within a
+ transaction, an
<literal>ER_WARNING_NOT_COMPLETE_ROLLBACK</literal> warning
occurs. Changes to transaction-safe tables are rolled back,
but not changes to non-transaction-safe tables.
@@ -224,18 +243,20 @@
</itemizedlist>
<para>
- If you are using <literal role="stmt" condition="commit">START TRANSACTION</literal> or
- <literal>SET AUTOCOMMIT=0</literal>, you should use the MySQL
- binary log for backups instead of the older update log.
- Transactions are stored in the binary log in one chunk, upon
- <literal role="stmt">COMMIT</literal>. Transactions that are rolled back are
- not logged. (<emphasis role="bold">Exception</emphasis>:
- Modifications to non-transactional tables cannot be rolled back.
- If a transaction that is rolled back includes modifications to
- non-transactional tables, the entire transaction is logged with a
- <literal role="stmt" condition="commit">ROLLBACK</literal> statement at the end to ensure that
- modifications to the non-transactional tables are replicated. This
- is true as of MySQL 4.0.15.) See <xref linkend="binary-log"/>.
+ If you are using <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> or <literal>SET AUTOCOMMIT=0</literal>, you
+ should use the MySQL binary log for backups instead of the older
+ update log. Transactions are stored in the binary log in one
+ chunk, upon <literal role="stmt">COMMIT</literal>. Transactions
+ that are rolled back are not logged.
+ (<emphasis role="bold">Exception</emphasis>: Modifications to
+ non-transactional tables cannot be rolled back. If a transaction
+ that is rolled back includes modifications to non-transactional
+ tables, the entire transaction is logged with a
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement at the end to ensure that modifications to the
+ non-transactional tables are replicated. This is true as of MySQL
+ 4.0.15.) See <xref linkend="binary-log"/>.
</para>
<para>
@@ -251,8 +272,9 @@
<literal role="stmt">SHOW PROCESSLIST</literal> displays
<literal>Rolling back</literal> in the <literal>State</literal>
column for the session, not only for explicit rollbacks performed
- with the <literal role="stmt" condition="commit">ROLLBACK</literal> statement but also for
- implicit rollbacks.
+ with the
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement but also for implicit rollbacks.
</para>
</section>
@@ -273,7 +295,9 @@
statements. If you issue a statement early in a transaction that
cannot be rolled back, and then another statement later fails, the
full effect of the transaction cannot be rolled back in such cases
- by issuing a <literal role="stmt" condition="commit">ROLLBACK</literal> statement.
+ by issuing a
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement.
</para>
</section>
@@ -285,7 +309,8 @@
<para>
The statements listed in this section (and any synonyms for them)
implicitly end a transaction, as if you had done a
- <literal role="stmt">COMMIT</literal> before executing the statement.
+ <literal role="stmt">COMMIT</literal> before executing the
+ statement.
</para>
<itemizedlist>
@@ -319,7 +344,8 @@
<para>
The <literal role="stmt">CREATE TABLE</literal> statement in
<literal>InnoDB</literal> is processed as a single
- transaction. This means that a <literal role="stmt" condition="commit">ROLLBACK</literal>
+ transaction. This means that a
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
from the user does not undo <literal role="stmt">CREATE
TABLE</literal> statements the user made during that
transaction.
@@ -340,10 +366,12 @@
<listitem>
<para>
<emphasis role="bold">Transaction-control and locking
- statements.</emphasis> <literal role="stmt" condition="commit">BEGIN</literal>,
+ statements.</emphasis>
+ <literal role="stmt" condition="commit">BEGIN</literal>,
<literal role="stmt">LOCK TABLES</literal>, <literal>SET
AUTOCOMMIT=1</literal> (if the value is not already 1),
- <literal role="stmt" condition="commit">START TRANSACTION</literal>,
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal>,
<literal role="stmt" condition="lock-tables">UNLOCK
TABLES</literal>.
</para>
@@ -363,8 +391,8 @@
<para>
Transactions cannot be nested. This is a consequence of the
implicit commit performed for any current transaction when you
- issue a <literal role="stmt" condition="commit">START TRANSACTION</literal> statement or one
- of its synonyms.
+ issue a <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> statement or one of its synonyms.
</para>
</listitem>
@@ -381,7 +409,8 @@
<section id="savepoints">
- <title><literal role="stmt">SAVEPOINT</literal> and <literal role="stmt" condition="commit">ROLLBACK TO
+ <title><literal role="stmt">SAVEPOINT</literal> and
+ <literal role="stmt" condition="commit">ROLLBACK TO
SAVEPOINT</literal> Syntax</title>
<indexterm>
@@ -411,38 +440,40 @@
<para>
Starting from MySQL 4.0.14 and 4.1.1, <literal>InnoDB</literal>
- supports the SQL statements <literal role="stmt">SAVEPOINT</literal> and
- <literal role="stmt" condition="commit">ROLLBACK TO SAVEPOINT</literal>.
+ supports the SQL statements
+ <literal role="stmt">SAVEPOINT</literal> and
+ <literal role="stmt" condition="commit">ROLLBACK TO
+ SAVEPOINT</literal>.
</para>
<remark role="help-description-end"/>
<para>
- The <literal role="stmt">SAVEPOINT</literal> statement sets a named
- transaction savepoint with a name of
+ The <literal role="stmt">SAVEPOINT</literal> statement sets a
+ named transaction savepoint with a name of
<replaceable>identifier</replaceable>. If the current transaction
has a savepoint with the same name, the old savepoint is deleted
and a new one is set.
</para>
<para>
- The <literal role="stmt" condition="commit">ROLLBACK TO SAVEPOINT</literal> statement rolls back
- a transaction to the named savepoint without terminating the
- transaction. Modifications that the current transaction made to
- rows after the savepoint was set are undone in the rollback, but
- <literal>InnoDB</literal> does <emphasis>not</emphasis> release
- the row locks that were stored in memory after the savepoint.
- (Note that for a new inserted row, the lock information is carried
- by the transaction ID stored in the row; the lock is not
- separately stored in memory. In this case, the row lock is
- released in the undo.) Savepoints that were set at a later time
- than the named savepoint are deleted.
+ The <literal role="stmt" condition="commit">ROLLBACK TO
+ SAVEPOINT</literal> statement rolls back a transaction to the
+ named savepoint without terminating the transaction. Modifications
+ that the current transaction made to rows after the savepoint was
+ set are undone in the rollback, but <literal>InnoDB</literal> does
+ <emphasis>not</emphasis> release the row locks that were stored in
+ memory after the savepoint. (Note that for a new inserted row, the
+ lock information is carried by the transaction ID stored in the
+ row; the lock is not separately stored in memory. In this case,
+ the row lock is released in the undo.) Savepoints that were set at
+ a later time than the named savepoint are deleted.
</para>
<para>
- If the <literal role="stmt" condition="commit">ROLLBACK TO SAVEPOINT</literal> statement returns
- the following error, it means that no savepoint with the specified
- name exists:
+ If the <literal role="stmt" condition="commit">ROLLBACK TO
+ SAVEPOINT</literal> statement returns the following error, it
+ means that no savepoint with the specified name exists:
</para>
<programlisting>
@@ -452,7 +483,8 @@
<para>
All savepoints of the current transaction are deleted if you
execute a <literal role="stmt">COMMIT</literal>, or a
- <literal role="stmt" condition="commit">ROLLBACK</literal> that does not name a savepoint.
+ <literal role="stmt" condition="commit">ROLLBACK</literal> that
+ does not name a savepoint.
</para>
</section>
@@ -595,7 +627,8 @@
<listitem>
<para>
- Beginning a transaction (for example, with <literal role="stmt" condition="commit">START
+ Beginning a transaction (for example, with
+ <literal role="stmt" condition="commit">START
TRANSACTION</literal>) implicitly performs an
<literal role="stmt" condition="lock-tables">UNLOCK
TABLES</literal>. (Additional information about the
@@ -833,7 +866,8 @@
<listitem>
<para>
- Beginning a transaction (for example, with <literal role="stmt" condition="commit">START
+ Beginning a transaction (for example, with
+ <literal role="stmt" condition="commit">START
TRANSACTION</literal>) implicitly commits any current
transaction and releases existing locks.
</para>
@@ -854,7 +888,8 @@
<literal role="stmt" condition="lock-tables">UNLOCK
TABLES</literal> with transactional tables, such as
<literal>InnoDB</literal> tables, is to begin a transaction
- with <literal>SET AUTOCOMMIT = 0</literal> (not <literal role="stmt" condition="commit">START
+ with <literal>SET AUTOCOMMIT = 0</literal> (not
+ <literal role="stmt" condition="commit">START
TRANSACTION</literal>) followed by <literal role="stmt">LOCK
TABLES</literal>, and to not call
<literal role="stmt" condition="lock-tables">UNLOCK
@@ -878,7 +913,8 @@
<listitem>
<para>
- <literal role="stmt" condition="commit">ROLLBACK</literal> does not release table locks.
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ does not release table locks.
</para>
</listitem>
Modified: trunk/refman-4.1/storage-engines.xml
===================================================================
--- trunk/refman-4.1/storage-engines.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-4.1/storage-engines.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 4, Lines Added: 25, Lines Deleted: 19; 4140 bytes
@@ -317,15 +317,16 @@
<listitem>
<para>
You can combine many statements and accept them all at the same
- time with the <literal role="stmt">COMMIT</literal> statement (if autocommit
- is disabled).
+ time with the <literal role="stmt">COMMIT</literal> statement
+ (if autocommit is disabled).
</para>
</listitem>
<listitem>
<para>
- You can execute <literal role="stmt" condition="commit">ROLLBACK</literal> to ignore your
- changes (if autocommit is disabled).
+ You can execute
+ <literal role="stmt" condition="commit">ROLLBACK</literal> to
+ ignore your changes (if autocommit is disabled).
</para>
</listitem>
@@ -2876,7 +2877,8 @@
called <literal>BDB</literal> for short. <literal>BDB</literal>
tables may have a greater chance of surviving crashes and are also
capable of <literal role="stmt">COMMIT</literal> and
- <literal role="stmt" condition="commit">ROLLBACK</literal> operations on transactions.
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ operations on transactions.
</para>
<para>
@@ -3371,15 +3373,18 @@
<para>
If you are running with autocommit disabled, changes do not
become permanent until you execute a
- <literal role="stmt">COMMIT</literal> statement. Instead of committing,
- you can execute <literal role="stmt" condition="commit">ROLLBACK</literal> to forget the
- changes.
+ <literal role="stmt">COMMIT</literal> statement. Instead of
+ committing, you can execute
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ to forget the changes.
</para>
<para>
- You can start a transaction with the <literal role="stmt" condition="commit">START
- TRANSACTION</literal> or <literal role="stmt" condition="commit">BEGIN</literal> statement
- to suspend autocommit, or with <literal>SET
+ You can start a transaction with the
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> or
+ <literal role="stmt" condition="commit">BEGIN</literal>
+ statement to suspend autocommit, or with <literal>SET
AUTOCOMMIT=0</literal> to disable autocommit explicitly.
</para>
</listitem>
@@ -3490,14 +3495,15 @@
maintaining this in a separate segment in each
<literal>BDB</literal> table. If you don't issue a lot of
<literal role="stmt">DELETE</literal> or
- <literal role="stmt" condition="commit">ROLLBACK</literal> statements, this number should
- be accurate enough for the MySQL optimizer. However, MySQL
- stores the number only on close, so it may be incorrect if
- the server terminates unexpectedly. It should not be fatal
- even if this number is not 100% correct. You can update the
- row count by using <literal role="stmt">ANALYZE
- TABLE</literal> or <literal role="stmt">OPTIMIZE
- TABLE</literal>. See <xref linkend="analyze-table"/>, and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statements, this number should be accurate enough for the
+ MySQL optimizer. However, MySQL stores the number only on
+ close, so it may be incorrect if the server terminates
+ unexpectedly. It should not be fatal even if this number is
+ not 100% correct. You can update the row count by using
+ <literal role="stmt">ANALYZE TABLE</literal> or
+ <literal role="stmt">OPTIMIZE TABLE</literal>. See
+ <xref linkend="analyze-table"/>, and
<xref linkend="optimize-table"/>.
</para>
</listitem>
Modified: trunk/refman-5.0/apis-c.xml
===================================================================
--- trunk/refman-5.0/apis-c.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.0/apis-c.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 9, Lines Deleted: 8; 1535 bytes
@@ -1740,14 +1740,15 @@
<para>
This command resets the state as if one had done a new connect.
(See <xref linkend="auto-reconnect"/>.) It always performs a
- <literal role="stmt" condition="commit">ROLLBACK</literal> of any active transactions, closes
- and drops all temporary tables, and unlocks all locked tables.
- Session system variables are reset to the values of the
- corresponding global system variables. Prepared statements are
- released and <literal role="stmt">HANDLER</literal> variables
- are closed. Locks acquired with
- <literal role="func">GET_LOCK()</literal> are released. These
- effects occur even if the user didn't change.
+ <literal role="stmt" condition="commit">ROLLBACK</literal> of
+ any active transactions, closes and drops all temporary tables,
+ and unlocks all locked tables. Session system variables are
+ reset to the values of the corresponding global system
+ variables. Prepared statements are released and
+ <literal role="stmt">HANDLER</literal> variables are closed.
+ Locks acquired with <literal role="func">GET_LOCK()</literal>
+ are released. These effects occur even if the user didn't
+ change.
</para>
<para>
Modified: trunk/refman-5.0/dba-core.xml
===================================================================
--- trunk/refman-5.0/dba-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.0/dba-core.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 5, Lines Added: 45, Lines Deleted: 37; 7448 bytes
@@ -3612,28 +3612,31 @@
<para>
If the value is 0 (the default),
<literal role="stmt">COMMIT</literal> and
- <literal role="stmt" condition="commit">ROLLBACK</literal> are unaffected.
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ are unaffected.
</para>
</listitem>
<listitem>
<para>
- If the value is 1, <literal role="stmt">COMMIT</literal> and
- <literal role="stmt" condition="commit">ROLLBACK</literal> are equivalent to
- <literal>COMMIT AND CHAIN</literal> and
- <literal>ROLLBACK AND CHAIN</literal>, respectively. (A
- new transaction starts immediately with the same
+ If the value is 1, <literal role="stmt">COMMIT</literal>
+ and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ are equivalent to <literal>COMMIT AND CHAIN</literal>
+ and <literal>ROLLBACK AND CHAIN</literal>, respectively.
+ (A new transaction starts immediately with the same
isolation level as the just-terminated transaction.)
</para>
</listitem>
<listitem>
<para>
- If the value is 2, <literal role="stmt">COMMIT</literal> and
- <literal role="stmt" condition="commit">ROLLBACK</literal> are equivalent to
- <literal>COMMIT RELEASE</literal> and <literal>ROLLBACK
- RELEASE</literal>, respectively. (The server disconnects
- after terminating the transaction.)
+ If the value is 2, <literal role="stmt">COMMIT</literal>
+ and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ are equivalent to <literal>COMMIT RELEASE</literal> and
+ <literal>ROLLBACK RELEASE</literal>, respectively. (The
+ server disconnects after terminating the transaction.)
</para>
</listitem>
@@ -7186,15 +7189,18 @@
<para>
Set the autocommit mode. If set to 1, all changes to a table
take effect immediately. If set to 0 you have to use
- <literal role="stmt">COMMIT</literal> to accept a transaction or
- <literal role="stmt" condition="commit">ROLLBACK</literal> to cancel it. By default, client
- connections begin with <literal>AUTOCOMMIT</literal> set to
- 1. If you change <literal>AUTOCOMMIT</literal> mode from 0
- to 1, MySQL performs an automatic <literal role="stmt">COMMIT</literal>
+ <literal role="stmt">COMMIT</literal> to accept a
+ transaction or
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ to cancel it. By default, client connections begin with
+ <literal>AUTOCOMMIT</literal> set to 1. If you change
+ <literal>AUTOCOMMIT</literal> mode from 0 to 1, MySQL
+ performs an automatic <literal role="stmt">COMMIT</literal>
of any open transaction. Another way to begin a transaction
- is to use a <literal role="stmt" condition="commit">START TRANSACTION</literal> or
- <literal role="stmt" condition="commit">BEGIN</literal> statement. See
- <xref linkend="commit"/>.
+ is to use a <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> or
+ <literal role="stmt" condition="commit">BEGIN</literal>
+ statement. See <xref linkend="commit"/>.
</para>
</listitem>
@@ -8729,7 +8735,8 @@
</para>
<para>
- The number of internal <literal role="stmt">COMMIT</literal> statements.
+ The number of internal <literal role="stmt">COMMIT</literal>
+ statements.
</para>
</listitem>
@@ -12139,23 +12146,24 @@
<literal role="stmt">INSERT</literal>) that change transactional
tables such as <literal>BDB</literal> or
<literal>InnoDB</literal> tables are cached until a
- <literal role="stmt">COMMIT</literal> statement is received by the server.
- At that point, <command>mysqld</command> writes the entire
- transaction to the binary log before the
- <literal role="stmt">COMMIT</literal> is executed. When the thread that
- handles the transaction starts, it allocates a buffer of
- <literal>binlog_cache_size</literal> to buffer statements. If a
- statement is bigger than this, the thread opens a temporary file
- to store the transaction. The temporary file is deleted when the
- thread ends.
+ <literal role="stmt">COMMIT</literal> statement is received by
+ the server. At that point, <command>mysqld</command> writes the
+ entire transaction to the binary log before the
+ <literal role="stmt">COMMIT</literal> is executed. When the
+ thread that handles the transaction starts, it allocates a
+ buffer of <literal>binlog_cache_size</literal> to buffer
+ statements. If a statement is bigger than this, the thread opens
+ a temporary file to store the transaction. The temporary file is
+ deleted when the thread ends.
</para>
<para>
Modifications to non-transactional tables cannot be rolled back.
If a transaction that is rolled back includes modifications to
non-transactional tables, the entire transaction is logged with
- a <literal role="stmt" condition="commit">ROLLBACK</literal> statement at the end to ensure
- that the modifications to those tables are replicated.
+ a <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement at the end to ensure that the modifications to those
+ tables are replicated.
</para>
<para>
@@ -12198,12 +12206,12 @@
chance of an inconsistency between the table content and binary
log content in case of a crash. For example, if you are using
<literal>InnoDB</literal> tables and the MySQL server processes
- a <literal role="stmt">COMMIT</literal> statement, it writes the whole
- transaction to the binary log and then commits this transaction
- into <literal>InnoDB</literal>. If the server crashes between
- those two operations, the transaction is rolled back by
- <literal>InnoDB</literal> at restart but still exists in the
- binary log. This problem can be solved with the
+ a <literal role="stmt">COMMIT</literal> statement, it writes the
+ whole transaction to the binary log and then commits this
+ transaction into <literal>InnoDB</literal>. If the server
+ crashes between those two operations, the transaction is rolled
+ back by <literal>InnoDB</literal> at restart but still exists in
+ the binary log. This problem can be solved with the
<option>--innodb-safe-binlog</option> option, which adds
consistency between the content of <literal>InnoDB</literal>
tables and the binary log. (Note:
Modified: trunk/refman-5.0/errors-problems.xml
===================================================================
--- trunk/refman-5.0/errors-problems.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.0/errors-problems.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 3, Lines Added: 8, Lines Deleted: 7; 1715 bytes
@@ -4322,9 +4322,9 @@
<para>
If you receive the following message when trying to perform a
- <literal role="stmt" condition="commit">ROLLBACK</literal>, it means that one or more of the
- tables you used in the transaction do not support
- transactions:
+ <literal role="stmt" condition="commit">ROLLBACK</literal>, it
+ means that one or more of the tables you used in the
+ transaction do not support transactions:
</para>
<programlisting>
@@ -4333,7 +4333,8 @@
<para>
These non-transactional tables are not affected by the
- <literal role="stmt" condition="commit">ROLLBACK</literal> statement.
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement.
</para>
<para>
@@ -5292,9 +5293,9 @@
<para>
<literal role="stmt" condition="flush">FLUSH TABLES WITH
READ LOCK</literal> does not block
- <literal role="stmt">COMMIT</literal> if the server is running without
- binary logging, which may cause a problem (of consistency
- between tables) when doing a full backup.
+ <literal role="stmt">COMMIT</literal> if the server is
+ running without binary logging, which may cause a problem
+ (of consistency between tables) when doing a full backup.
</para>
</listitem>
Modified: trunk/refman-5.0/faqs.xml
===================================================================
--- trunk/refman-5.0/faqs.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.0/faqs.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 1; 711 bytes
@@ -4321,7 +4321,8 @@
supported. A failed insert due to a duplicate key or
similar error causes a transaction to abort; when this
occurs, you must issue an explicit
- <literal role="stmt" condition="commit">ROLLBACK</literal> and retry the transaction.
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ and retry the transaction.
</para>
</listitem>
Modified: trunk/refman-5.0/functions-core.xml
===================================================================
--- trunk/refman-5.0/functions-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.0/functions-core.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 6, Lines Deleted: 4; 1218 bytes
@@ -15161,10 +15161,12 @@
undefined. For transactional tables, if the statement is
rolled back due to an error, the value of
<literal role="func">LAST_INSERT_ID()</literal> is left
- undefined. For manual <literal role="stmt" condition="commit">ROLLBACK</literal>, the value
- of <literal role="func">LAST_INSERT_ID()</literal> is not
- restored to that before the transaction; it remains as it
- was at the point of the <literal role="stmt" condition="commit">ROLLBACK</literal>.
+ undefined. For manual
+ <literal role="stmt" condition="commit">ROLLBACK</literal>,
+ the value of <literal role="func">LAST_INSERT_ID()</literal>
+ is not restored to that before the transaction; it remains
+ as it was at the point of the
+ <literal role="stmt" condition="commit">ROLLBACK</literal>.
</para>
<para>
Modified: trunk/refman-5.0/introduction.xml
===================================================================
--- trunk/refman-5.0/introduction.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.0/introduction.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 3, Lines Added: 16, Lines Deleted: 14; 2769 bytes
@@ -1794,13 +1794,13 @@
<para>
If your applications are written in a way that is
dependent on being able to call
- <literal role="stmt" condition="commit">ROLLBACK</literal> rather than
- <literal role="stmt">COMMIT</literal> in critical situations,
- transactions are more convenient. Transactions also ensure
- that unfinished updates or corrupting activities are not
- committed to the database; the server is given the
- opportunity to do an automatic rollback and your database
- is saved.
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ rather than <literal role="stmt">COMMIT</literal> in
+ critical situations, transactions are more convenient.
+ Transactions also ensure that unfinished updates or
+ corrupting activities are not committed to the database;
+ the server is given the opportunity to do an automatic
+ rollback and your database is saved.
</para>
<para>
@@ -1897,8 +1897,9 @@
<listitem>
<para>
- To avoid using <literal role="stmt" condition="commit">ROLLBACK</literal>, you can employ
- the following strategy:
+ To avoid using
+ <literal role="stmt" condition="commit">ROLLBACK</literal>,
+ you can employ the following strategy:
</para>
<orderedlist>
@@ -2021,11 +2022,12 @@
</indexterm>
In many cases, users have wanted <literal role="stmt">LOCK
- TABLES</literal> or <literal role="stmt" condition="commit">ROLLBACK</literal> for the
- purpose of managing unique identifiers. This can be
- handled much more efficiently without locking or rolling
- back by using an <literal>AUTO_INCREMENT</literal> column
- and either the
+ TABLES</literal> or
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ for the purpose of managing unique identifiers. This can
+ be handled much more efficiently without locking or
+ rolling back by using an <literal>AUTO_INCREMENT</literal>
+ column and either the
<literal role="func">LAST_INSERT_ID()</literal> SQL
function or the
<literal role="cfunc">mysql_insert_id()</literal> C API
Modified: trunk/refman-5.0/mysql-cluster-limitations.xml
===================================================================
--- trunk/refman-5.0/mysql-cluster-limitations.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.0/mysql-cluster-limitations.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 3, Lines Deleted: 2; 830 bytes
@@ -523,8 +523,9 @@
statements raise <errortext>ERROR 1296 (HY000): Got error
4350 'Transaction already aborted' from
NDBCLUSTER</errortext>. In such cases, you must issue an
- explicit <literal role="stmt" condition="commit">ROLLBACK</literal> and retry the entire
- transaction.
+ explicit
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ and retry the entire transaction.
</para>
</formalpara>
Modified: trunk/refman-5.0/optimization.xml
===================================================================
--- trunk/refman-5.0/optimization.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.0/optimization.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 1; 702 bytes
@@ -6440,7 +6440,8 @@
<para>
To obtain faster insertions for transactional tables, you
- should use <literal role="stmt" condition="commit">START TRANSACTION</literal> and
+ should use <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> and
<literal role="stmt">COMMIT</literal> instead of
<literal role="stmt">LOCK TABLES</literal>.
</para>
Modified: trunk/refman-5.0/programs-client-core.xml
===================================================================
--- trunk/refman-5.0/programs-client-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.0/programs-client-core.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 2, Lines Added: 11, Lines Deleted: 9; 1797 bytes
@@ -6518,8 +6518,8 @@
<para>
Enclose the <literal role="stmt">INSERT</literal> statements
for each dumped table within <literal>SET
- AUTOCOMMIT=0</literal> and <literal role="stmt">COMMIT</literal>
- statements.
+ AUTOCOMMIT=0</literal> and
+ <literal role="stmt">COMMIT</literal> statements.
</para>
</listitem>
@@ -6918,13 +6918,15 @@
</para>
<para>
- This option issues a <literal role="stmt" condition="commit">BEGIN</literal> SQL statement
- before dumping data from the server. It is useful only with
- transactional tables such as <literal>InnoDB</literal> and
- <literal>BDB</literal>, because then it dumps the consistent
- state of the database at the time when
- <literal role="stmt" condition="commit">BEGIN</literal> was issued without blocking any
- applications.
+ This option issues a
+ <literal role="stmt" condition="commit">BEGIN</literal> SQL
+ statement before dumping data from the server. It is useful
+ only with transactional tables such as
+ <literal>InnoDB</literal> and <literal>BDB</literal>,
+ because then it dumps the consistent state of the database
+ at the time when
+ <literal role="stmt" condition="commit">BEGIN</literal> was
+ issued without blocking any applications.
</para>
<para>
Modified: trunk/refman-5.0/replication-configuration.xml
===================================================================
--- trunk/refman-5.0/replication-configuration.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.0/replication-configuration.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 2; 711 bytes
@@ -443,8 +443,8 @@
<para>
For <literal>InnoDB</literal> tables, note that
<literal role="stmt" condition="flush">FLUSH TABLES WITH
- READ LOCK</literal> also blocks <literal role="stmt">COMMIT</literal>
- operations.
+ READ LOCK</literal> also blocks
+ <literal role="stmt">COMMIT</literal> operations.
</para>
<warning>
Modified: trunk/refman-5.0/replication-notes.xml
===================================================================
--- trunk/refman-5.0/replication-notes.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.0/replication-notes.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 4, Lines Added: 8, Lines Deleted: 5; 2774 bytes
@@ -1038,8 +1038,8 @@
can replicate an <literal>InnoDB</literal> master table as a
<literal>MyISAM</literal> slave table. However, if you do this,
there are problems if the slave is stopped in the middle of a
- <literal role="stmt" condition="commit">BEGIN</literal>/<literal role="stmt">COMMIT</literal> block because
- the slave restarts at the beginning of the
+ <literal role="stmt" condition="commit">BEGIN</literal>/<literal role="stmt">COMMIT</literal>
+ block because the slave restarts at the beginning of the
<literal role="stmt" condition="commit">BEGIN</literal> block.
</para>
@@ -1047,7 +1047,8 @@
In situations where transactions mix updates to transactional
and non-transactional tables, the order of statements in the
binary log is correct, and all needed statements are written to
- the binary log even in case of a <literal role="stmt" condition="commit">ROLLBACK</literal>.
+ the binary log even in case of a
+ <literal role="stmt" condition="commit">ROLLBACK</literal>.
However, when a second connection updates the non-transactional
table before the first connection's transaction is complete,
statements can be logged out of order, because the second
@@ -1073,7 +1074,8 @@
<para>
If you update transactional tables from non-transactional tables
- inside a <literal role="stmt" condition="commit">BEGIN</literal>/<literal role="stmt">COMMIT</literal>
+ inside a
+ <literal role="stmt" condition="commit">BEGIN</literal>/<literal role="stmt">COMMIT</literal>
sequence, updates to the binary log may be out of synchrony with
table states if the non-transactional table is updated before
the transaction commits. This occurs because the transaction is
@@ -1084,7 +1086,8 @@
In situations where transactions mix updates to transactional
and non-transactional tables, the order of statements in the
binary log is correct, and all needed statements are written to
- the binary log even in case of a <literal role="stmt" condition="commit">ROLLBACK</literal>.
+ the binary log even in case of a
+ <literal role="stmt" condition="commit">ROLLBACK</literal>.
However, when a second connection updates the non-transactional
table before the first connection's transaction is complete,
statements can be logged out of order, because the second
Modified: trunk/refman-5.0/se-bdb-core.xml
===================================================================
--- trunk/refman-5.0/se-bdb-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.0/se-bdb-core.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 3, Lines Added: 19, Lines Deleted: 13; 3288 bytes
@@ -33,7 +33,8 @@
transactional storage engine. This storage engine typically is
called <literal>BDB</literal> for short. <literal>BDB</literal>
tables may have a greater chance of surviving crashes and are also
- capable of <literal role="stmt">COMMIT</literal> and <literal role="stmt" condition="commit">ROLLBACK</literal>
+ capable of <literal role="stmt">COMMIT</literal> and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
operations on transactions.
</para>
@@ -521,15 +522,19 @@
<listitem>
<para>
If you are running with autocommit disabled, changes do not
- become permanent until you execute a <literal role="stmt">COMMIT</literal>
- statement. Instead of committing, you can execute
- <literal role="stmt" condition="commit">ROLLBACK</literal> to forget the changes.
+ become permanent until you execute a
+ <literal role="stmt">COMMIT</literal> statement. Instead of
+ committing, you can execute
+ <literal role="stmt" condition="commit">ROLLBACK</literal> to
+ forget the changes.
</para>
<para>
- You can start a transaction with the <literal role="stmt" condition="commit">START
- TRANSACTION</literal> or <literal role="stmt" condition="commit">BEGIN</literal> statement to
- suspend autocommit, or with <literal>SET
+ You can start a transaction with the
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> or
+ <literal role="stmt" condition="commit">BEGIN</literal>
+ statement to suspend autocommit, or with <literal>SET
AUTOCOMMIT=0</literal> to disable autocommit explicitly.
</para>
</listitem>
@@ -639,12 +644,13 @@
maintaining this in a separate segment in each
<literal>BDB</literal> table. If you don't issue a lot of
<literal role="stmt">DELETE</literal> or
- <literal role="stmt" condition="commit">ROLLBACK</literal> statements, this number should be
- accurate enough for the MySQL optimizer. However, MySQL stores
- the number only on close, so it may be incorrect if the server
- terminates unexpectedly. It should not be fatal even if this
- number is not 100% correct. You can update the row count by
- using <literal role="stmt">ANALYZE TABLE</literal> or
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statements, this number should be accurate enough for the
+ MySQL optimizer. However, MySQL stores the number only on
+ close, so it may be incorrect if the server terminates
+ unexpectedly. It should not be fatal even if this number is
+ not 100% correct. You can update the row count by using
+ <literal role="stmt">ANALYZE TABLE</literal> or
<literal role="stmt">OPTIMIZE TABLE</literal>. See
<xref linkend="analyze-table"/>, and
<xref linkend="optimize-table"/>.
Modified: trunk/refman-5.0/se-innodb-core.xml
===================================================================
--- trunk/refman-5.0/se-innodb-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.0/se-innodb-core.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 10, Lines Added: 49, Lines Deleted: 34; 8407 bytes
@@ -2229,10 +2229,12 @@
transactions, you can switch autocommit off with the SQL
statement <literal>SET AUTOCOMMIT = 0</literal> and end each
transaction with either <literal role="stmt">COMMIT</literal> or
- <literal role="stmt" condition="commit">ROLLBACK</literal>. If you want to leave autocommit on,
- you can begin your transactions within <literal role="stmt" condition="commit">START
+ <literal role="stmt" condition="commit">ROLLBACK</literal>. If
+ you want to leave autocommit on, you can begin your transactions
+ within <literal role="stmt" condition="commit">START
TRANSACTION</literal> and end them with
- <literal role="stmt">COMMIT</literal> or <literal role="stmt" condition="commit">ROLLBACK</literal>. The
+ <literal role="stmt">COMMIT</literal> or
+ <literal role="stmt" condition="commit">ROLLBACK</literal>. The
following example shows two transactions. The first is
committed; the second is rolled back.
</para>
@@ -2268,9 +2270,9 @@
<para>
In APIs such as PHP, Perl DBI, JDBC, ODBC, or the standard C
call interface of MySQL, you can send transaction control
- statements such as <literal role="stmt">COMMIT</literal> to the MySQL server
- as strings just like any other SQL statements such as
- <literal role="stmt">SELECT</literal> or
+ statements such as <literal role="stmt">COMMIT</literal> to the
+ MySQL server as strings just like any other SQL statements such
+ as <literal role="stmt">SELECT</literal> or
<literal role="stmt">INSERT</literal>. Some APIs also offer
separate special transaction commit and rollback functions or
methods.
@@ -4211,14 +4213,17 @@
<para>
If autocommit mode is disabled within a session with
<literal>SET AUTOCOMMIT = 0</literal>, the session always has a
- transaction open. An SQL <literal role="stmt">COMMIT</literal> or
- <literal role="stmt" condition="commit">ROLLBACK</literal> statement ends the current
- transaction and a new one starts. A <literal role="stmt">COMMIT</literal>
- means that the changes made in the current transaction are made
- permanent and become visible to other sessions. A
- <literal role="stmt" condition="commit">ROLLBACK</literal> statement, on the other hand,
- cancels all modifications made by the current transaction. Both
- <literal role="stmt">COMMIT</literal> and <literal role="stmt" condition="commit">ROLLBACK</literal>
+ transaction open. An SQL <literal role="stmt">COMMIT</literal>
+ or <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement ends the current transaction and a new one starts. A
+ <literal role="stmt">COMMIT</literal> means that the changes
+ made in the current transaction are made permanent and become
+ visible to other sessions. A
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement, on the other hand, cancels all modifications made by
+ the current transaction. Both
+ <literal role="stmt">COMMIT</literal> and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
release all <literal>InnoDB</literal> locks that were set during
the current transaction.
</para>
@@ -4226,9 +4231,11 @@
<para>
If the session has autocommit enabled, a multiple-statement
transaction can be performed by starting it with an explicit
- <literal role="stmt" condition="commit">START TRANSACTION</literal> or
-<literal role="stmt" condition="commit">BEGIN</literal>
- statement and ending it with <literal role="stmt">COMMIT</literal> or
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> or
+ <literal role="stmt" condition="commit">BEGIN</literal>
+ statement and ending it with
+ <literal role="stmt">COMMIT</literal> or
<literal role="stmt" condition="commit">ROLLBACK</literal>.
</para>
@@ -4533,7 +4540,8 @@
<para>
Locking of rows for update using <literal>SELECT FOR
UPDATE</literal> only applies when autocommit is disabled
- (either by beginning transaction with <literal role="stmt" condition="commit">START
+ (either by beginning transaction with
+ <literal role="stmt" condition="commit">START
TRANSACTION</literal> or by setting
<literal>AUTOCOMMIT</literal> to 0. If autocommit is enabled,
the rows matching the specification are not locked.
@@ -4916,8 +4924,9 @@
<para>
For details about which statements implicitly end a transaction,
- as if you had done a <literal role="stmt">COMMIT</literal> before executing
- the statement, see <xref linkend="implicit-commit"/>.
+ as if you had done a <literal role="stmt">COMMIT</literal>
+ before executing the statement, see
+ <xref linkend="implicit-commit"/>.
</para>
</section>
@@ -5255,8 +5264,9 @@
that MySQL does not have autocommit mode enabled because that
requires a log flush to disk for every insert. To disable
autocommit during your import operation, surround it with
- <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal> and
- <literal role="stmt">COMMIT</literal> statements:
+ <literal role="stmt" condition="commit">SET
+ AUTOCOMMIT</literal> and <literal role="stmt">COMMIT</literal>
+ statements:
</para>
<programlisting>
@@ -5269,8 +5279,10 @@
If you use the <command>mysqldump</command> option
<option>--opt</option>, you get dump files that are fast to
import into an <literal>InnoDB</literal> table, even without
- wrapping them with the <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal> and
- <literal role="stmt">COMMIT</literal> statements.
+ wrapping them with the
+ <literal role="stmt" condition="commit">SET
+ AUTOCOMMIT</literal> and <literal role="stmt">COMMIT</literal>
+ statements.
</para>
</listitem>
@@ -6499,12 +6511,14 @@
When a transaction rollback occurs due to a deadlock or lock
wait timeout, it cancels the effect of the statements within
the transaction. But if the start-transaction statement was
- <literal role="stmt" condition="commit">START TRANSACTION</literal> or
- <literal role="stmt" condition="commit">BEGIN</literal> statement, rollback does not cancel
- that statement. Further SQL statements become part of the
- transaction until the occurrence of <literal role="stmt">COMMIT</literal>,
- <literal role="stmt" condition="commit">ROLLBACK</literal>, or some SQL statement that causes
- an implicit commit.
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> or
+ <literal role="stmt" condition="commit">BEGIN</literal>
+ statement, rollback does not cancel that statement. Further
+ SQL statements become part of the transaction until the
+ occurrence of <literal role="stmt">COMMIT</literal>,
+ <literal role="stmt" condition="commit">ROLLBACK</literal>, or
+ some SQL statement that causes an implicit commit.
</para>
</listitem>
@@ -6536,10 +6550,11 @@
<para>
During implicit rollbacks, as well as during the execution of an
- explicit <literal role="stmt" condition="commit">ROLLBACK</literal> SQL statement,
- <literal role="stmt">SHOW PROCESSLIST</literal> displays
- <literal>Rolling back</literal> in the <literal>State</literal>
- column for the relevant connection.
+ explicit
+ <literal role="stmt" condition="commit">ROLLBACK</literal> SQL
+ statement, <literal role="stmt">SHOW PROCESSLIST</literal>
+ displays <literal>Rolling back</literal> in the
+ <literal>State</literal> column for the relevant connection.
</para>
<section id="innodb-error-codes">
Modified: trunk/refman-5.0/sql-syntax-data-definition.xml
===================================================================
--- trunk/refman-5.0/sql-syntax-data-definition.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.0/sql-syntax-data-definition.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 6, Lines Deleted: 5; 1225 bytes
@@ -2304,11 +2304,12 @@
MySQL allows routines to contain DDL statements, such as
<literal>CREATE</literal> and <literal>DROP</literal>. MySQL also
allows stored procedures (but not stored functions) to contain SQL
- transaction statements such as <literal role="stmt">COMMIT</literal>. Stored
- functions may not contain statements that perform explicit or
- implicit commit or rollback. Support for these statements is not
- required by the SQL standard, which states that each DBMS vendor
- may decide whether to allow them.
+ transaction statements such as
+ <literal role="stmt">COMMIT</literal>. Stored functions may not
+ contain statements that perform explicit or implicit commit or
+ rollback. Support for these statements is not required by the SQL
+ standard, which states that each DBMS vendor may decide whether to
+ allow them.
</para>
<para>
Modified: trunk/refman-5.0/sql-syntax-transactions.xml
===================================================================
--- trunk/refman-5.0/sql-syntax-transactions.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.0/sql-syntax-transactions.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 23, Lines Added: 131, Lines Deleted: 92; 21091 bytes
@@ -11,17 +11,20 @@
<para>
MySQL supports local transactions (within a given client session)
- through statements such as <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal>,
- <literal role="stmt" condition="commit">START TRANSACTION</literal>, <literal role="stmt">COMMIT</literal>, and
- <literal role="stmt" condition="commit">ROLLBACK</literal>. See <xref linkend="commit"/>. Beginning
- with MySQL 5.0, XA transaction support is available, which enables
- MySQL to participate in distributed transactions as well. See
- <xref linkend="xa"/>.
+ through statements such as
+ <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal>,
+ <literal role="stmt" condition="commit">START TRANSACTION</literal>,
+ <literal role="stmt">COMMIT</literal>, and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>. See
+ <xref linkend="commit"/>. Beginning with MySQL 5.0, XA transaction
+ support is available, which enables MySQL to participate in
+ distributed transactions as well. See <xref linkend="xa"/>.
</para>
<section id="commit">
- <title><literal role="stmt" condition="commit">START TRANSACTION</literal>, <literal role="stmt">COMMIT</literal>, and
+ <title><literal role="stmt" condition="commit">START TRANSACTION</literal>,
+ <literal role="stmt">COMMIT</literal>, and
<literal role="stmt" condition="commit">ROLLBACK</literal> Syntax</title>
<indexterm>
@@ -59,24 +62,27 @@
<remark role="help-description-begin"/>
<para>
- The <literal role="stmt" condition="commit">START TRANSACTION</literal> or
- <literal role="stmt" condition="commit">BEGIN</literal> statement begins a new transaction.
- <literal role="stmt">COMMIT</literal> commits the current transaction, making
- its changes permanent. <literal role="stmt" condition="commit">ROLLBACK</literal> rolls back the
- current transaction, canceling its changes. The <literal role="stmt" condition="commit">SET
- AUTOCOMMIT</literal> statement disables or enables the default
- autocommit mode for the current session.
+ The <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> or
+ <literal role="stmt" condition="commit">BEGIN</literal> statement
+ begins a new transaction. <literal role="stmt">COMMIT</literal>
+ commits the current transaction, making its changes permanent.
+ <literal role="stmt" condition="commit">ROLLBACK</literal> rolls
+ back the current transaction, canceling its changes. The
+ <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal>
+ statement disables or enables the default autocommit mode for the
+ current session.
</para>
<para>
Beginning with MySQL 5.0.3, the optional <literal>WORK</literal>
keyword is supported for <literal role="stmt">COMMIT</literal> and
- <literal role="stmt" condition="commit">ROLLBACK</literal>, as are the <literal>CHAIN</literal>
- and <literal>RELEASE</literal> clauses. <literal>CHAIN</literal>
- and <literal>RELEASE</literal> can be used for additional control
- over transaction completion. The value of the
- <literal>completion_type</literal> system variable determines the
- default completion behavior. See
+ <literal role="stmt" condition="commit">ROLLBACK</literal>, as are
+ the <literal>CHAIN</literal> and <literal>RELEASE</literal>
+ clauses. <literal>CHAIN</literal> and <literal>RELEASE</literal>
+ can be used for additional control over transaction completion.
+ The value of the <literal>completion_type</literal> system
+ variable determines the default completion behavior. See
<xref linkend="server-system-variables"/>.
</para>
@@ -110,13 +116,16 @@
transaction-safe tables (such as those for
<literal>InnoDB</literal>, <literal>BDB</literal>, or
<literal>NDBCLUSTER</literal>) are not made permanent immediately.
- You must use <literal role="stmt">COMMIT</literal> to store your changes to
- disk or <literal role="stmt" condition="commit">ROLLBACK</literal> to ignore the changes.
+ You must use <literal role="stmt">COMMIT</literal> to store your
+ changes to disk or
+ <literal role="stmt" condition="commit">ROLLBACK</literal> to
+ ignore the changes.
</para>
<para>
To disable autocommit mode for a single series of statements, use
- the <literal role="stmt" condition="commit">START TRANSACTION</literal> statement:
+ the <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> statement:
</para>
<remark role="help-description-end"/>
@@ -131,18 +140,22 @@
</programlisting>
<para>
- With <literal role="stmt" condition="commit">START TRANSACTION</literal>, autocommit remains
- disabled until you end the transaction with
- <literal role="stmt">COMMIT</literal> or <literal role="stmt" condition="commit">ROLLBACK</literal>. The
+ With <literal role="stmt" condition="commit">START
+ TRANSACTION</literal>, autocommit remains disabled until you end
+ the transaction with <literal role="stmt">COMMIT</literal> or
+ <literal role="stmt" condition="commit">ROLLBACK</literal>. The
autocommit mode then reverts to its previous state.
</para>
<para>
- <literal role="stmt" condition="commit">BEGIN</literal> and <literal role="stmt" condition="commit">BEGIN WORK</literal> are
- supported as aliases of <literal role="stmt" condition="commit">START TRANSACTION</literal> for
- initiating a transaction. <literal role="stmt" condition="commit">START TRANSACTION</literal> is
- standard SQL syntax and is the recommended way to start an ad-hoc
- transaction.
+ <literal role="stmt" condition="commit">BEGIN</literal> and
+ <literal role="stmt" condition="commit">BEGIN WORK</literal> are
+ supported as aliases of
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> for initiating a transaction.
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> is standard SQL syntax and is the
+ recommended way to start an ad-hoc transaction.
</para>
<important>
@@ -150,17 +163,19 @@
Many APIs used for writing MySQL client applications (such as
JDBC) provide their own methods for starting transactions that
can (and sometimes should) be used instead of sending a
- <literal role="stmt" condition="commit">START TRANSACTION</literal> statement from the client.
- See <xref linkend="connectors-apis"/>, or the documentation for
- your API, for more information.
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> statement from the client. See
+ <xref linkend="connectors-apis"/>, or the documentation for your
+ API, for more information.
</para>
</important>
<para>
- The <literal role="stmt" condition="commit">BEGIN</literal> statement differs from the use of the
- <literal>BEGIN</literal> keyword that starts a <literal>BEGIN ...
- END</literal> compound statement. The latter does not begin a
- transaction. See <xref linkend="begin-end"/>.
+ The <literal role="stmt" condition="commit">BEGIN</literal>
+ statement differs from the use of the <literal>BEGIN</literal>
+ keyword that starts a <literal>BEGIN ... END</literal> compound
+ statement. The latter does not begin a transaction. See
+ <xref linkend="begin-end"/>.
</para>
<para>
@@ -175,7 +190,8 @@
The <literal>WITH CONSISTENT SNAPSHOT</literal> clause starts a
consistent read for storage engines that are capable of it. This
applies only to <literal>InnoDB</literal>. The effect is the same
- as issuing a <literal role="stmt" condition="commit">START TRANSACTION</literal> followed by a
+ as issuing a <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> followed by a
<literal role="stmt">SELECT</literal> from any
<literal>InnoDB</literal> table. See
<xref linkend="innodb-consistent-read"/>. The <literal>WITH
@@ -239,8 +255,10 @@
<listitem>
<para>
- If you issue a <literal role="stmt" condition="commit">ROLLBACK</literal> statement after
- updating a non-transactional table within a transaction, an
+ If you issue a
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement after updating a non-transactional table within a
+ transaction, an
<literal>ER_WARNING_NOT_COMPLETE_ROLLBACK</literal> warning
occurs. Changes to transaction-safe tables are rolled back,
but not changes to non-transaction-safe tables.
@@ -251,13 +269,15 @@
<para>
Each transaction is stored in the binary log in one chunk, upon
- <literal role="stmt">COMMIT</literal>. Transactions that are rolled back are
- not logged. (<emphasis role="bold">Exception</emphasis>:
- Modifications to non-transactional tables cannot be rolled back.
- If a transaction that is rolled back includes modifications to
- non-transactional tables, the entire transaction is logged with a
- <literal role="stmt" condition="commit">ROLLBACK</literal> statement at the end to ensure that
- modifications to the non-transactional tables are replicated.) See
+ <literal role="stmt">COMMIT</literal>. Transactions that are
+ rolled back are not logged.
+ (<emphasis role="bold">Exception</emphasis>: Modifications to
+ non-transactional tables cannot be rolled back. If a transaction
+ that is rolled back includes modifications to non-transactional
+ tables, the entire transaction is logged with a
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement at the end to ensure that modifications to the
+ non-transactional tables are replicated.) See
<xref linkend="binary-log"/>.
</para>
@@ -273,7 +293,8 @@
an error occurs). Because of this, <literal role="stmt">SHOW
PROCESSLIST</literal> displays <literal>Rolling back</literal> in
the <literal>State</literal> column for the session, not only for
- explicit rollbacks performed with the <literal role="stmt" condition="commit">ROLLBACK</literal>
+ explicit rollbacks performed with the
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
statement but also for implicit rollbacks.
</para>
@@ -295,7 +316,9 @@
statements. If you issue a statement early in a transaction that
cannot be rolled back, and then another statement later fails, the
full effect of the transaction cannot be rolled back in such cases
- by issuing a <literal role="stmt" condition="commit">ROLLBACK</literal> statement.
+ by issuing a
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement.
</para>
</section>
@@ -307,7 +330,8 @@
<para>
The statements listed in this section (and any synonyms for them)
implicitly end a transaction, as if you had done a
- <literal role="stmt">COMMIT</literal> before executing the statement.
+ <literal role="stmt">COMMIT</literal> before executing the
+ statement.
</para>
<itemizedlist>
@@ -341,7 +365,8 @@
<para>
The <literal role="stmt">CREATE TABLE</literal> statement in
<literal>InnoDB</literal> is processed as a single
- transaction. This means that a <literal role="stmt" condition="commit">ROLLBACK</literal>
+ transaction. This means that a
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
from the user does not undo <literal role="stmt">CREATE
TABLE</literal> statements the user made during that
transaction.
@@ -389,10 +414,12 @@
<listitem>
<para>
<emphasis role="bold">Transaction-control and locking
- statements.</emphasis> <literal role="stmt" condition="commit">BEGIN</literal>,
+ statements.</emphasis>
+ <literal role="stmt" condition="commit">BEGIN</literal>,
<literal role="stmt">LOCK TABLES</literal>, <literal>SET
AUTOCOMMIT=1</literal> (if the value is not already 1),
- <literal role="stmt" condition="commit">START TRANSACTION</literal>,
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal>,
<literal role="stmt" condition="lock-tables">UNLOCK
TABLES</literal>.
</para>
@@ -412,8 +439,8 @@
<para>
Transactions cannot be nested. This is a consequence of the
implicit commit performed for any current transaction when you
- issue a <literal role="stmt" condition="commit">START TRANSACTION</literal> statement or one
- of its synonyms.
+ issue a <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> statement or one of its synonyms.
</para>
<para>
@@ -423,11 +450,11 @@
</para>
<para>
- The <literal role="stmt" condition="commit">BEGIN</literal> statement differs from the use of
- the <literal>BEGIN</literal> keyword that starts a
- <literal>BEGIN ... END</literal> compound statement. The
- latter does not cause an implicit commit. See
- <xref linkend="begin-end"/>.
+ The <literal role="stmt" condition="commit">BEGIN</literal>
+ statement differs from the use of the <literal>BEGIN</literal>
+ keyword that starts a <literal>BEGIN ... END</literal>
+ compound statement. The latter does not cause an implicit
+ commit. See <xref linkend="begin-end"/>.
</para>
</listitem>
@@ -451,7 +478,8 @@
<section id="savepoints">
- <title><literal role="stmt">SAVEPOINT</literal> and <literal role="stmt" condition="commit">ROLLBACK TO
+ <title><literal role="stmt">SAVEPOINT</literal> and
+ <literal role="stmt" condition="commit">ROLLBACK TO
SAVEPOINT</literal> Syntax</title>
<indexterm>
@@ -486,41 +514,46 @@
<para>
<literal>InnoDB</literal> supports the SQL statements
- <literal role="stmt">SAVEPOINT</literal> and <literal role="stmt" condition="commit">ROLLBACK TO
- SAVEPOINT</literal>. Starting from MySQL 5.0.3, <literal role="stmt" condition="commit">RELEASE
+ <literal role="stmt">SAVEPOINT</literal> and
+ <literal role="stmt" condition="commit">ROLLBACK TO
+ SAVEPOINT</literal>. Starting from MySQL 5.0.3,
+ <literal role="stmt" condition="commit">RELEASE
SAVEPOINT</literal> and the optional <literal>WORK</literal>
- keyword for <literal role="stmt" condition="commit">ROLLBACK</literal> are supported as well.
+ keyword for
+ <literal role="stmt" condition="commit">ROLLBACK</literal> are
+ supported as well.
</para>
<remark role="help-description-end"/>
<para>
- The <literal role="stmt">SAVEPOINT</literal> statement sets a named
- transaction savepoint with a name of
+ The <literal role="stmt">SAVEPOINT</literal> statement sets a
+ named transaction savepoint with a name of
<replaceable>identifier</replaceable>. If the current transaction
has a savepoint with the same name, the old savepoint is deleted
and a new one is set.
</para>
<para>
- The <literal role="stmt" condition="commit">ROLLBACK TO SAVEPOINT</literal> statement rolls back
- a transaction to the named savepoint without terminating the
- transaction. (The <literal role="stmt">SAVEPOINT</literal> keyword is optional
- as of MySQL 5.0.3.) Modifications that the current transaction
- made to rows after the savepoint was set are undone in the
- rollback, but <literal>InnoDB</literal> does
- <emphasis>not</emphasis> release the row locks that were stored in
- memory after the savepoint. (Note that for a new inserted row, the
- lock information is carried by the transaction ID stored in the
- row; the lock is not separately stored in memory. In this case,
- the row lock is released in the undo.) Savepoints that were set at
- a later time than the named savepoint are deleted.
+ The <literal role="stmt" condition="commit">ROLLBACK TO
+ SAVEPOINT</literal> statement rolls back a transaction to the
+ named savepoint without terminating the transaction. (The
+ <literal role="stmt">SAVEPOINT</literal> keyword is optional as of
+ MySQL 5.0.3.) Modifications that the current transaction made to
+ rows after the savepoint was set are undone in the rollback, but
+ <literal>InnoDB</literal> does <emphasis>not</emphasis> release
+ the row locks that were stored in memory after the savepoint.
+ (Note that for a new inserted row, the lock information is carried
+ by the transaction ID stored in the row; the lock is not
+ separately stored in memory. In this case, the row lock is
+ released in the undo.) Savepoints that were set at a later time
+ than the named savepoint are deleted.
</para>
<para>
- If the <literal role="stmt" condition="commit">ROLLBACK TO SAVEPOINT</literal> statement returns
- the following error, it means that no savepoint with the specified
- name exists:
+ If the <literal role="stmt" condition="commit">ROLLBACK TO
+ SAVEPOINT</literal> statement returns the following error, it
+ means that no savepoint with the specified name exists:
</para>
<programlisting>
@@ -528,16 +561,17 @@
</programlisting>
<para>
- The <literal role="stmt" condition="commit">RELEASE SAVEPOINT</literal> statement removes the
- named savepoint from the set of savepoints of the current
- transaction. No commit or rollback occurs. It is an error if the
- savepoint does not exist.
+ The <literal role="stmt" condition="commit">RELEASE
+ SAVEPOINT</literal> statement removes the named savepoint from the
+ set of savepoints of the current transaction. No commit or
+ rollback occurs. It is an error if the savepoint does not exist.
</para>
<para>
All savepoints of the current transaction are deleted if you
execute a <literal role="stmt">COMMIT</literal>, or a
- <literal role="stmt" condition="commit">ROLLBACK</literal> that does not name a savepoint.
+ <literal role="stmt" condition="commit">ROLLBACK</literal> that
+ does not name a savepoint.
</para>
<para>
@@ -688,7 +722,8 @@
<listitem>
<para>
- Beginning a transaction (for example, with <literal role="stmt" condition="commit">START
+ Beginning a transaction (for example, with
+ <literal role="stmt" condition="commit">START
TRANSACTION</literal>) implicitly performs an
<literal role="stmt" condition="lock-tables">UNLOCK
TABLES</literal>. (Additional information about the
@@ -926,7 +961,8 @@
<listitem>
<para>
- Beginning a transaction (for example, with <literal role="stmt" condition="commit">START
+ Beginning a transaction (for example, with
+ <literal role="stmt" condition="commit">START
TRANSACTION</literal>) implicitly commits any current
transaction and releases existing locks.
</para>
@@ -947,7 +983,8 @@
<literal role="stmt" condition="lock-tables">UNLOCK
TABLES</literal> with transactional tables, such as
<literal>InnoDB</literal> tables, is to begin a transaction
- with <literal>SET AUTOCOMMIT = 0</literal> (not <literal role="stmt" condition="commit">START
+ with <literal>SET AUTOCOMMIT = 0</literal> (not
+ <literal role="stmt" condition="commit">START
TRANSACTION</literal>) followed by <literal role="stmt">LOCK
TABLES</literal>, and to not call
<literal role="stmt" condition="lock-tables">UNLOCK
@@ -971,7 +1008,8 @@
<listitem>
<para>
- <literal role="stmt" condition="commit">ROLLBACK</literal> does not release table locks.
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ does not release table locks.
</para>
</listitem>
@@ -1858,7 +1896,8 @@
START</literal> has been issued to begin an XA transaction, a
local transaction cannot be started until the XA transaction has
been committed or rolled back. Conversely, if a local
- transaction has been started with <literal role="stmt" condition="commit">START
+ transaction has been started with
+ <literal role="stmt" condition="commit">START
TRANSACTION</literal>, no XA statements can be used until the
transaction has been committed or rolled back.
</para>
Modified: trunk/refman-5.0/storage-engines.xml
===================================================================
--- trunk/refman-5.0/storage-engines.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.0/storage-engines.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 5, Lines Deleted: 4; 984 bytes
@@ -341,15 +341,16 @@
<listitem>
<para>
You can combine many statements and accept them all at the same
- time with the <literal role="stmt">COMMIT</literal> statement (if autocommit
- is disabled).
+ time with the <literal role="stmt">COMMIT</literal> statement
+ (if autocommit is disabled).
</para>
</listitem>
<listitem>
<para>
- You can execute <literal role="stmt" condition="commit">ROLLBACK</literal> to ignore your
- changes (if autocommit is disabled).
+ You can execute
+ <literal role="stmt" condition="commit">ROLLBACK</literal> to
+ ignore your changes (if autocommit is disabled).
</para>
</listitem>
Modified: trunk/refman-5.0/stored-programs-views.xml
===================================================================
--- trunk/refman-5.0/stored-programs-views.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.0/stored-programs-views.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 2, Lines Added: 16, Lines Deleted: 11; 2895 bytes
@@ -1115,18 +1115,21 @@
that the transactional aspects of procedure execution are
replicated correctly. That is, the server logs those
statements within the procedure that actually execute and
- modify data, and also logs <literal role="stmt" condition="commit">BEGIN</literal>,
- <literal role="stmt">COMMIT</literal>, and <literal role="stmt" condition="commit">ROLLBACK</literal>
+ modify data, and also logs
+ <literal role="stmt" condition="commit">BEGIN</literal>,
+ <literal role="stmt">COMMIT</literal>, and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
statements as necessary. For example, if a procedure
updates only transactional tables and is executed within a
transaction that is rolled back, those updates are not
logged. If the procedure occurs within a committed
- transaction, <literal role="stmt" condition="commit">BEGIN</literal> and
- <literal role="stmt">COMMIT</literal> statements are logged with the
- updates. For a procedure that executes within a
- rolled-back transaction, its statements are logged using
- the same rules that would apply if the statements were
- executed in standalone fashion:
+ transaction,
+ <literal role="stmt" condition="commit">BEGIN</literal>
+ and <literal role="stmt">COMMIT</literal> statements are
+ logged with the updates. For a procedure that executes
+ within a rolled-back transaction, its statements are
+ logged using the same rules that would apply if the
+ statements were executed in standalone fashion:
</para>
<itemizedlist>
@@ -1148,9 +1151,11 @@
<para>
Updates to a mix of transactional and
non-transactional tables are logged surrounded by
- <literal role="stmt" condition="commit">BEGIN</literal> and
- <literal role="stmt" condition="commit">ROLLBACK</literal> so that slaves will make
- the same changes and rollbacks as on the master.
+ <literal role="stmt" condition="commit">BEGIN</literal>
+ and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ so that slaves will make the same changes and
+ rollbacks as on the master.
</para>
</listitem>
Modified: trunk/refman-5.0/triggers.xml
===================================================================
--- trunk/refman-5.0/triggers.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.0/triggers.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 4, Lines Deleted: 3; 898 bytes
@@ -340,9 +340,10 @@
<listitem>
<para>
The trigger cannot use statements that explicitly or
- implicitly begin or end a transaction such as <literal role="stmt" condition="commit">START
- TRANSACTION</literal>, <literal role="stmt">COMMIT</literal>, or
- <literal role="stmt" condition="commit">ROLLBACK</literal>.
+ implicitly begin or end a transaction such as
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal>, <literal role="stmt">COMMIT</literal>,
+ or <literal role="stmt" condition="commit">ROLLBACK</literal>.
</para>
</listitem>
Modified: trunk/refman-5.1/apis-c.xml
===================================================================
--- trunk/refman-5.1/apis-c.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.1/apis-c.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 9, Lines Deleted: 8; 1535 bytes
@@ -1725,14 +1725,15 @@
<para>
This command resets the state as if one had done a new connect.
(See <xref linkend="auto-reconnect"/>.) It always performs a
- <literal role="stmt" condition="commit">ROLLBACK</literal> of any active transactions, closes
- and drops all temporary tables, and unlocks all locked tables.
- Session system variables are reset to the values of the
- corresponding global system variables. Prepared statements are
- released and <literal role="stmt">HANDLER</literal> variables
- are closed. Locks acquired with
- <literal role="func">GET_LOCK()</literal> are released. These
- effects occur even if the user didn't change.
+ <literal role="stmt" condition="commit">ROLLBACK</literal> of
+ any active transactions, closes and drops all temporary tables,
+ and unlocks all locked tables. Session system variables are
+ reset to the values of the corresponding global system
+ variables. Prepared statements are released and
+ <literal role="stmt">HANDLER</literal> variables are closed.
+ Locks acquired with <literal role="func">GET_LOCK()</literal>
+ are released. These effects occur even if the user didn't
+ change.
</para>
<para>
Modified: trunk/refman-5.1/dba-core.xml
===================================================================
--- trunk/refman-5.1/dba-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.1/dba-core.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 5, Lines Added: 45, Lines Deleted: 37; 7472 bytes
@@ -4306,28 +4306,31 @@
<para>
If the value is 0 (the default),
<literal role="stmt">COMMIT</literal> and
- <literal role="stmt" condition="commit">ROLLBACK</literal> are unaffected.
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ are unaffected.
</para>
</listitem>
<listitem>
<para>
- If the value is 1, <literal role="stmt">COMMIT</literal> and
- <literal role="stmt" condition="commit">ROLLBACK</literal> are equivalent to
- <literal>COMMIT AND CHAIN</literal> and
- <literal>ROLLBACK AND CHAIN</literal>, respectively. (A
- new transaction starts immediately with the same
+ If the value is 1, <literal role="stmt">COMMIT</literal>
+ and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ are equivalent to <literal>COMMIT AND CHAIN</literal>
+ and <literal>ROLLBACK AND CHAIN</literal>, respectively.
+ (A new transaction starts immediately with the same
isolation level as the just-terminated transaction.)
</para>
</listitem>
<listitem>
<para>
- If the value is 2, <literal role="stmt">COMMIT</literal> and
- <literal role="stmt" condition="commit">ROLLBACK</literal> are equivalent to
- <literal>COMMIT RELEASE</literal> and <literal>ROLLBACK
- RELEASE</literal>, respectively. (The server disconnects
- after terminating the transaction.)
+ If the value is 2, <literal role="stmt">COMMIT</literal>
+ and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ are equivalent to <literal>COMMIT RELEASE</literal> and
+ <literal>ROLLBACK RELEASE</literal>, respectively. (The
+ server disconnects after terminating the transaction.)
</para>
</listitem>
@@ -8490,15 +8493,18 @@
<para>
Set the autocommit mode. If set to 1, all changes to a table
take effect immediately. If set to 0 you have to use
- <literal role="stmt">COMMIT</literal> to accept a transaction or
- <literal role="stmt" condition="commit">ROLLBACK</literal> to cancel it. By default, client
- connections begin with <literal>AUTOCOMMIT</literal> set to
- 1. If you change <literal>AUTOCOMMIT</literal> mode from 0
- to 1, MySQL performs an automatic <literal role="stmt">COMMIT</literal>
+ <literal role="stmt">COMMIT</literal> to accept a
+ transaction or
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ to cancel it. By default, client connections begin with
+ <literal>AUTOCOMMIT</literal> set to 1. If you change
+ <literal>AUTOCOMMIT</literal> mode from 0 to 1, MySQL
+ performs an automatic <literal role="stmt">COMMIT</literal>
of any open transaction. Another way to begin a transaction
- is to use a <literal role="stmt" condition="commit">START TRANSACTION</literal> or
- <literal role="stmt" condition="commit">BEGIN</literal> statement. See
- <xref linkend="commit"/>.
+ is to use a <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> or
+ <literal role="stmt" condition="commit">BEGIN</literal>
+ statement. See <xref linkend="commit"/>.
</para>
</listitem>
@@ -10013,7 +10019,8 @@
</para>
<para>
- The number of internal <literal role="stmt">COMMIT</literal> statements.
+ The number of internal <literal role="stmt">COMMIT</literal>
+ statements.
</para>
</listitem>
@@ -14123,23 +14130,24 @@
<literal role="stmt">INSERT</literal>) that change transactional
tables such as <literal>BDB</literal> or
<literal>InnoDB</literal> tables are cached until a
- <literal role="stmt">COMMIT</literal> statement is received by the server.
- At that point, <command>mysqld</command> writes the entire
- transaction to the binary log before the
- <literal role="stmt">COMMIT</literal> is executed. When the thread that
- handles the transaction starts, it allocates a buffer of
- <literal>binlog_cache_size</literal> to buffer statements. If a
- statement is bigger than this, the thread opens a temporary file
- to store the transaction. The temporary file is deleted when the
- thread ends.
+ <literal role="stmt">COMMIT</literal> statement is received by
+ the server. At that point, <command>mysqld</command> writes the
+ entire transaction to the binary log before the
+ <literal role="stmt">COMMIT</literal> is executed. When the
+ thread that handles the transaction starts, it allocates a
+ buffer of <literal>binlog_cache_size</literal> to buffer
+ statements. If a statement is bigger than this, the thread opens
+ a temporary file to store the transaction. The temporary file is
+ deleted when the thread ends.
</para>
<para>
Modifications to non-transactional tables cannot be rolled back.
If a transaction that is rolled back includes modifications to
non-transactional tables, the entire transaction is logged with
- a <literal role="stmt" condition="commit">ROLLBACK</literal> statement at the end to ensure
- that the modifications to those tables are replicated.
+ a <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement at the end to ensure that the modifications to those
+ tables are replicated.
</para>
<para>
@@ -14192,12 +14200,12 @@
chance of an inconsistency between the table content and binary
log content in case of a crash. For example, if you are using
<literal>InnoDB</literal> tables and the MySQL server processes
- a <literal role="stmt">COMMIT</literal> statement, it writes the whole
- transaction to the binary log and then commits this transaction
- into <literal>InnoDB</literal>. If the server crashes between
- those two operations, the transaction is rolled back by
- <literal>InnoDB</literal> at restart but still exists in the
- binary log. To resolve this, you should set
+ a <literal role="stmt">COMMIT</literal> statement, it writes the
+ whole transaction to the binary log and then commits this
+ transaction into <literal>InnoDB</literal>. If the server
+ crashes between those two operations, the transaction is rolled
+ back by <literal>InnoDB</literal> at restart but still exists in
+ the binary log. To resolve this, you should set
<option>--innodb_support_xa</option> to 1. Although this option
is related to the support of XA transactions in InnoDB, it also
ensures that the binary log and InnoDB data files are
Modified: trunk/refman-5.1/errors-problems-core.xml
===================================================================
--- trunk/refman-5.1/errors-problems-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.1/errors-problems-core.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 3, Lines Added: 8, Lines Deleted: 7; 1730 bytes
@@ -4318,9 +4318,9 @@
<para>
If you receive the following message when trying to perform a
- <literal role="stmt" condition="commit">ROLLBACK</literal>, it means that one or more of the
- tables you used in the transaction do not support
- transactions:
+ <literal role="stmt" condition="commit">ROLLBACK</literal>, it
+ means that one or more of the tables you used in the
+ transaction do not support transactions:
</para>
<programlisting>
@@ -4329,7 +4329,8 @@
<para>
These non-transactional tables are not affected by the
- <literal role="stmt" condition="commit">ROLLBACK</literal> statement.
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement.
</para>
<para>
@@ -5208,9 +5209,9 @@
<para>
<literal role="stmt" condition="flush">FLUSH TABLES WITH
READ LOCK</literal> does not block
- <literal role="stmt">COMMIT</literal> if the server is running without
- binary logging, which may cause a problem (of consistency
- between tables) when doing a full backup.
+ <literal role="stmt">COMMIT</literal> if the server is
+ running without binary logging, which may cause a problem
+ (of consistency between tables) when doing a full backup.
</para>
</listitem>
Modified: trunk/refman-5.1/functions-core.xml
===================================================================
--- trunk/refman-5.1/functions-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.1/functions-core.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 6, Lines Deleted: 4; 1218 bytes
@@ -16433,10 +16433,12 @@
undefined. For transactional tables, if the statement is
rolled back due to an error, the value of
<literal role="func">LAST_INSERT_ID()</literal> is left
- undefined. For manual <literal role="stmt" condition="commit">ROLLBACK</literal>, the value
- of <literal role="func">LAST_INSERT_ID()</literal> is not
- restored to that before the transaction; it remains as it
- was at the point of the <literal role="stmt" condition="commit">ROLLBACK</literal>.
+ undefined. For manual
+ <literal role="stmt" condition="commit">ROLLBACK</literal>,
+ the value of <literal role="func">LAST_INSERT_ID()</literal>
+ is not restored to that before the transaction; it remains
+ as it was at the point of the
+ <literal role="stmt" condition="commit">ROLLBACK</literal>.
</para>
<para>
Modified: trunk/refman-5.1/introduction.xml
===================================================================
--- trunk/refman-5.1/introduction.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.1/introduction.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 3, Lines Added: 16, Lines Deleted: 14; 2769 bytes
@@ -1941,13 +1941,13 @@
<para>
If your applications are written in a way that is
dependent on being able to call
- <literal role="stmt" condition="commit">ROLLBACK</literal> rather than
- <literal role="stmt">COMMIT</literal> in critical situations,
- transactions are more convenient. Transactions also ensure
- that unfinished updates or corrupting activities are not
- committed to the database; the server is given the
- opportunity to do an automatic rollback and your database
- is saved.
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ rather than <literal role="stmt">COMMIT</literal> in
+ critical situations, transactions are more convenient.
+ Transactions also ensure that unfinished updates or
+ corrupting activities are not committed to the database;
+ the server is given the opportunity to do an automatic
+ rollback and your database is saved.
</para>
<para>
@@ -2044,8 +2044,9 @@
<listitem>
<para>
- To avoid using <literal role="stmt" condition="commit">ROLLBACK</literal>, you can employ
- the following strategy:
+ To avoid using
+ <literal role="stmt" condition="commit">ROLLBACK</literal>,
+ you can employ the following strategy:
</para>
<orderedlist>
@@ -2168,11 +2169,12 @@
</indexterm>
In many cases, users have wanted <literal role="stmt">LOCK
- TABLES</literal> or <literal role="stmt" condition="commit">ROLLBACK</literal> for the
- purpose of managing unique identifiers. This can be
- handled much more efficiently without locking or rolling
- back by using an <literal>AUTO_INCREMENT</literal> column
- and either the
+ TABLES</literal> or
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ for the purpose of managing unique identifiers. This can
+ be handled much more efficiently without locking or
+ rolling back by using an <literal>AUTO_INCREMENT</literal>
+ column and either the
<literal role="func">LAST_INSERT_ID()</literal> SQL
function or the
<literal role="cfunc">mysql_insert_id()</literal> C API
Modified: trunk/refman-5.1/mysql-cluster-limitations.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-limitations.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.1/mysql-cluster-limitations.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 2; 803 bytes
@@ -1947,8 +1947,8 @@
<errortext>ERROR 1296 (HY000): Got error 4350 'Transaction
already aborted' from NDBCLUSTER</errortext>. In such
cases, it was necessary to issue an explicit
- <literal role="stmt" condition="commit">ROLLBACK</literal> and retry the entire
- transaction.
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ and retry the entire transaction.
</para>
</formalpara>
Modified: trunk/refman-5.1/optimization.xml
===================================================================
--- trunk/refman-5.1/optimization.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.1/optimization.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 1; 702 bytes
@@ -7295,7 +7295,8 @@
<para>
To obtain faster insertions for transactional tables, you
- should use <literal role="stmt" condition="commit">START TRANSACTION</literal> and
+ should use <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> and
<literal role="stmt">COMMIT</literal> instead of
<literal role="stmt">LOCK TABLES</literal>.
</para>
Modified: trunk/refman-5.1/programs-client-core.xml
===================================================================
--- trunk/refman-5.1/programs-client-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.1/programs-client-core.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 2, Lines Added: 10, Lines Deleted: 8; 1719 bytes
@@ -6763,8 +6763,8 @@
<para>
Enclose the <literal role="stmt">INSERT</literal> statements
for each dumped table within <literal>SET
- AUTOCOMMIT=0</literal> and <literal role="stmt">COMMIT</literal>
- statements.
+ AUTOCOMMIT=0</literal> and
+ <literal role="stmt">COMMIT</literal> statements.
</para>
</listitem>
@@ -7185,12 +7185,14 @@
</para>
<para>
- This option issues a <literal role="stmt" condition="commit">BEGIN</literal> SQL statement
- before dumping data from the server. It is useful only with
- transactional tables such as <literal>InnoDB</literal>,
- because then it dumps the consistent state of the database
- at the time when <literal role="stmt" condition="commit">BEGIN</literal> was issued without
- blocking any applications.
+ This option issues a
+ <literal role="stmt" condition="commit">BEGIN</literal> SQL
+ statement before dumping data from the server. It is useful
+ only with transactional tables such as
+ <literal>InnoDB</literal>, because then it dumps the
+ consistent state of the database at the time when
+ <literal role="stmt" condition="commit">BEGIN</literal> was
+ issued without blocking any applications.
</para>
<para>
Modified: trunk/refman-5.1/replication-configuration-core.xml
===================================================================
--- trunk/refman-5.1/replication-configuration-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.1/replication-configuration-core.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 2; 726 bytes
@@ -455,8 +455,8 @@
<para>
For <literal>InnoDB</literal> tables, note that
<literal role="stmt" condition="flush">FLUSH TABLES WITH
- READ LOCK</literal> also blocks <literal role="stmt">COMMIT</literal>
- operations.
+ READ LOCK</literal> also blocks
+ <literal role="stmt">COMMIT</literal> operations.
</para>
<warning>
Modified: trunk/refman-5.1/replication-notes.xml
===================================================================
--- trunk/refman-5.1/replication-notes.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.1/replication-notes.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 2, Lines Added: 4, Lines Deleted: 3; 1572 bytes
@@ -1844,8 +1844,8 @@
can replicate an <literal>InnoDB</literal> master table as a
<literal>MyISAM</literal> slave table. However, if you do this,
there are problems if the slave is stopped in the middle of a
- <literal role="stmt" condition="commit">BEGIN</literal>/<literal role="stmt">COMMIT</literal> block because
- the slave restarts at the beginning of the
+ <literal role="stmt" condition="commit">BEGIN</literal>/<literal role="stmt">COMMIT</literal>
+ block because the slave restarts at the beginning of the
<literal role="stmt" condition="commit">BEGIN</literal> block.
</para>
@@ -1853,7 +1853,8 @@
In situations where transactions mix updates to transactional
and non-transactional tables, the order of statements in the
binary log is correct, and all needed statements are written to
- the binary log even in case of a <literal role="stmt" condition="commit">ROLLBACK</literal>.
+ the binary log even in case of a
+ <literal role="stmt" condition="commit">ROLLBACK</literal>.
However, when a second connection updates the non-transactional
table before the first connection's transaction is complete,
statements can be logged out of order, because the second
Modified: trunk/refman-5.1/se-innodb-core.xml
===================================================================
--- trunk/refman-5.1/se-innodb-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.1/se-innodb-core.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 11, Lines Added: 55, Lines Deleted: 39; 9457 bytes
@@ -2264,10 +2264,12 @@
transactions, you can switch autocommit off with the SQL
statement <literal>SET AUTOCOMMIT = 0</literal> and end each
transaction with either <literal role="stmt">COMMIT</literal> or
- <literal role="stmt" condition="commit">ROLLBACK</literal>. If you want to leave autocommit on,
- you can begin your transactions within <literal role="stmt" condition="commit">START
+ <literal role="stmt" condition="commit">ROLLBACK</literal>. If
+ you want to leave autocommit on, you can begin your transactions
+ within <literal role="stmt" condition="commit">START
TRANSACTION</literal> and end them with
- <literal role="stmt">COMMIT</literal> or <literal role="stmt" condition="commit">ROLLBACK</literal>. The
+ <literal role="stmt">COMMIT</literal> or
+ <literal role="stmt" condition="commit">ROLLBACK</literal>. The
following example shows two transactions. The first is
committed; the second is rolled back.
</para>
@@ -2303,9 +2305,9 @@
<para>
In APIs such as PHP, Perl DBI, JDBC, ODBC, or the standard C
call interface of MySQL, you can send transaction control
- statements such as <literal role="stmt">COMMIT</literal> to the MySQL server
- as strings just like any other SQL statements such as
- <literal role="stmt">SELECT</literal> or
+ statements such as <literal role="stmt">COMMIT</literal> to the
+ MySQL server as strings just like any other SQL statements such
+ as <literal role="stmt">SELECT</literal> or
<literal role="stmt">INSERT</literal>. Some APIs also offer
separate special transaction commit and rollback functions or
methods.
@@ -4910,14 +4912,17 @@
<para>
If autocommit mode is disabled within a session with
<literal>SET AUTOCOMMIT = 0</literal>, the session always has a
- transaction open. An SQL <literal role="stmt">COMMIT</literal> or
- <literal role="stmt" condition="commit">ROLLBACK</literal> statement ends the current
- transaction and a new one starts. A <literal role="stmt">COMMIT</literal>
- means that the changes made in the current transaction are made
- permanent and become visible to other sessions. A
- <literal role="stmt" condition="commit">ROLLBACK</literal> statement, on the other hand,
- cancels all modifications made by the current transaction. Both
- <literal role="stmt">COMMIT</literal> and <literal role="stmt" condition="commit">ROLLBACK</literal>
+ transaction open. An SQL <literal role="stmt">COMMIT</literal>
+ or <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement ends the current transaction and a new one starts. A
+ <literal role="stmt">COMMIT</literal> means that the changes
+ made in the current transaction are made permanent and become
+ visible to other sessions. A
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement, on the other hand, cancels all modifications made by
+ the current transaction. Both
+ <literal role="stmt">COMMIT</literal> and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
release all <literal>InnoDB</literal> locks that were set during
the current transaction.
</para>
@@ -4925,9 +4930,11 @@
<para>
If the session has autocommit enabled, a multiple-statement
transaction can be performed by starting it with an explicit
- <literal role="stmt" condition="commit">START TRANSACTION</literal> or
-<literal role="stmt" condition="commit">BEGIN</literal>
- statement and ending it with <literal role="stmt">COMMIT</literal> or
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> or
+ <literal role="stmt" condition="commit">BEGIN</literal>
+ statement and ending it with
+ <literal role="stmt">COMMIT</literal> or
<literal role="stmt" condition="commit">ROLLBACK</literal>.
</para>
@@ -5242,7 +5249,8 @@
<para>
Locking of rows for update using <literal>SELECT FOR
UPDATE</literal> only applies when autocommit is disabled
- (either by beginning transaction with <literal role="stmt" condition="commit">START
+ (either by beginning transaction with
+ <literal role="stmt" condition="commit">START
TRANSACTION</literal> or by setting
<literal>AUTOCOMMIT</literal> to 0. If autocommit is enabled,
the rows matching the specification are not locked.
@@ -5648,8 +5656,9 @@
<para>
For details about which statements implicitly end a transaction,
- as if you had done a <literal role="stmt">COMMIT</literal> before executing
- the statement, see <xref linkend="implicit-commit"/>.
+ as if you had done a <literal role="stmt">COMMIT</literal>
+ before executing the statement, see
+ <xref linkend="implicit-commit"/>.
</para>
</section>
@@ -5694,11 +5703,12 @@
As of MySQL 5.1.24, if a <literal role="stmt">SELECT</literal>
calls a stored function in a transaction, and a statement within
the function fails, that statement rolls back. Furthermore, if
- <literal role="stmt" condition="commit">ROLLBACK</literal> is executed after that, the entire
- transaction rolls back. Before 5.1.24, the failed statement did
- not roll back when it failed (even though it might ultimately
- get rolled back by a <literal role="stmt" condition="commit">ROLLBACK</literal> later that
- rolls back the entire transaction).
+ <literal role="stmt" condition="commit">ROLLBACK</literal> is
+ executed after that, the entire transaction rolls back. Before
+ 5.1.24, the failed statement did not roll back when it failed
+ (even though it might ultimately get rolled back by a
+ <literal role="stmt" condition="commit">ROLLBACK</literal> later
+ that rolls back the entire transaction).
</para>
</section>
@@ -5998,8 +6008,9 @@
that MySQL does not have autocommit mode enabled because that
requires a log flush to disk for every insert. To disable
autocommit during your import operation, surround it with
- <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal> and
- <literal role="stmt">COMMIT</literal> statements:
+ <literal role="stmt" condition="commit">SET
+ AUTOCOMMIT</literal> and <literal role="stmt">COMMIT</literal>
+ statements:
</para>
<programlisting>
@@ -6012,8 +6023,10 @@
If you use the <command>mysqldump</command> option
<option>--opt</option>, you get dump files that are fast to
import into an <literal>InnoDB</literal> table, even without
- wrapping them with the <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal> and
- <literal role="stmt">COMMIT</literal> statements.
+ wrapping them with the
+ <literal role="stmt" condition="commit">SET
+ AUTOCOMMIT</literal> and <literal role="stmt">COMMIT</literal>
+ statements.
</para>
</listitem>
@@ -7244,12 +7257,14 @@
When a transaction rollback occurs due to a deadlock or lock
wait timeout, it cancels the effect of the statements within
the transaction. But if the start-transaction statement was
- <literal role="stmt" condition="commit">START TRANSACTION</literal> or
- <literal role="stmt" condition="commit">BEGIN</literal> statement, rollback does not cancel
- that statement. Further SQL statements become part of the
- transaction until the occurrence of <literal role="stmt">COMMIT</literal>,
- <literal role="stmt" condition="commit">ROLLBACK</literal>, or some SQL statement that causes
- an implicit commit.
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> or
+ <literal role="stmt" condition="commit">BEGIN</literal>
+ statement, rollback does not cancel that statement. Further
+ SQL statements become part of the transaction until the
+ occurrence of <literal role="stmt">COMMIT</literal>,
+ <literal role="stmt" condition="commit">ROLLBACK</literal>, or
+ some SQL statement that causes an implicit commit.
</para>
</listitem>
@@ -7281,10 +7296,11 @@
<para>
During implicit rollbacks, as well as during the execution of an
- explicit <literal role="stmt" condition="commit">ROLLBACK</literal> SQL statement,
- <literal role="stmt">SHOW PROCESSLIST</literal> displays
- <literal>Rolling back</literal> in the <literal>State</literal>
- column for the relevant connection.
+ explicit
+ <literal role="stmt" condition="commit">ROLLBACK</literal> SQL
+ statement, <literal role="stmt">SHOW PROCESSLIST</literal>
+ displays <literal>Rolling back</literal> in the
+ <literal>State</literal> column for the relevant connection.
</para>
<section id="innodb-error-codes">
Modified: trunk/refman-5.1/sql-syntax-data-definition.xml
===================================================================
--- trunk/refman-5.1/sql-syntax-data-definition.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.1/sql-syntax-data-definition.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 6, Lines Deleted: 5; 1225 bytes
@@ -4425,11 +4425,12 @@
MySQL allows routines to contain DDL statements, such as
<literal>CREATE</literal> and <literal>DROP</literal>. MySQL also
allows stored procedures (but not stored functions) to contain SQL
- transaction statements such as <literal role="stmt">COMMIT</literal>. Stored
- functions may not contain statements that perform explicit or
- implicit commit or rollback. Support for these statements is not
- required by the SQL standard, which states that each DBMS vendor
- may decide whether to allow them.
+ transaction statements such as
+ <literal role="stmt">COMMIT</literal>. Stored functions may not
+ contain statements that perform explicit or implicit commit or
+ rollback. Support for these statements is not required by the SQL
+ standard, which states that each DBMS vendor may decide whether to
+ allow them.
</para>
<para>
Modified: trunk/refman-5.1/sql-syntax-transactions.xml
===================================================================
--- trunk/refman-5.1/sql-syntax-transactions.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.1/sql-syntax-transactions.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 23, Lines Added: 123, Lines Deleted: 85; 20141 bytes
@@ -11,16 +11,20 @@
<para>
MySQL supports local transactions (within a given client session)
- through statements such as <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal>,
- <literal role="stmt" condition="commit">START TRANSACTION</literal>, <literal role="stmt">COMMIT</literal>, and
- <literal role="stmt" condition="commit">ROLLBACK</literal>. See <xref linkend="commit"/>. XA
- transaction support enables MySQL to participate in distributed
- transactions as well. See <xref linkend="xa"/>.
+ through statements such as
+ <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal>,
+ <literal role="stmt" condition="commit">START TRANSACTION</literal>,
+ <literal role="stmt">COMMIT</literal>, and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>. See
+ <xref linkend="commit"/>. XA transaction support enables MySQL to
+ participate in distributed transactions as well. See
+ <xref linkend="xa"/>.
</para>
<section id="commit">
- <title><literal role="stmt" condition="commit">START TRANSACTION</literal>, <literal role="stmt">COMMIT</literal>, and
+ <title><literal role="stmt" condition="commit">START TRANSACTION</literal>,
+ <literal role="stmt">COMMIT</literal>, and
<literal role="stmt" condition="commit">ROLLBACK</literal> Syntax</title>
<indexterm>
@@ -58,18 +62,22 @@
<remark role="help-description-begin"/>
<para>
- The <literal role="stmt" condition="commit">START TRANSACTION</literal> or
- <literal role="stmt" condition="commit">BEGIN</literal> statement begins a new transaction.
- <literal role="stmt">COMMIT</literal> commits the current transaction, making
- its changes permanent. <literal role="stmt" condition="commit">ROLLBACK</literal> rolls back the
- current transaction, canceling its changes. The <literal role="stmt" condition="commit">SET
- AUTOCOMMIT</literal> statement disables or enables the default
- autocommit mode for the current session.
+ The <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> or
+ <literal role="stmt" condition="commit">BEGIN</literal> statement
+ begins a new transaction. <literal role="stmt">COMMIT</literal>
+ commits the current transaction, making its changes permanent.
+ <literal role="stmt" condition="commit">ROLLBACK</literal> rolls
+ back the current transaction, canceling its changes. The
+ <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal>
+ statement disables or enables the default autocommit mode for the
+ current session.
</para>
<para>
The optional <literal>WORK</literal> keyword is supported for
- <literal role="stmt">COMMIT</literal> and <literal role="stmt" condition="commit">ROLLBACK</literal>, as are
+ <literal role="stmt">COMMIT</literal> and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>, as are
the <literal>CHAIN</literal> and <literal>RELEASE</literal>
clauses. <literal>CHAIN</literal> and <literal>RELEASE</literal>
can be used for additional control over transaction completion.
@@ -108,13 +116,15 @@
transaction-safe tables (such as those for
<literal>InnoDB</literal> or <literal>NDBCLUSTER</literal>) are
not made permanent immediately. You must use
- <literal role="stmt">COMMIT</literal> to store your changes to disk or
- <literal role="stmt" condition="commit">ROLLBACK</literal> to ignore the changes.
+ <literal role="stmt">COMMIT</literal> to store your changes to
+ disk or <literal role="stmt" condition="commit">ROLLBACK</literal>
+ to ignore the changes.
</para>
<para>
To disable autocommit mode for a single series of statements, use
- the <literal role="stmt" condition="commit">START TRANSACTION</literal> statement:
+ the <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> statement:
</para>
<remark role="help-description-end"/>
@@ -129,18 +139,22 @@
</programlisting>
<para>
- With <literal role="stmt" condition="commit">START TRANSACTION</literal>, autocommit remains
- disabled until you end the transaction with
- <literal role="stmt">COMMIT</literal> or <literal role="stmt" condition="commit">ROLLBACK</literal>. The
+ With <literal role="stmt" condition="commit">START
+ TRANSACTION</literal>, autocommit remains disabled until you end
+ the transaction with <literal role="stmt">COMMIT</literal> or
+ <literal role="stmt" condition="commit">ROLLBACK</literal>. The
autocommit mode then reverts to its previous state.
</para>
<para>
- <literal role="stmt" condition="commit">BEGIN</literal> and <literal role="stmt" condition="commit">BEGIN WORK</literal> are
- supported as aliases of <literal role="stmt" condition="commit">START TRANSACTION</literal> for
- initiating a transaction. <literal role="stmt" condition="commit">START TRANSACTION</literal> is
- standard SQL syntax and is the recommended way to start an ad-hoc
- transaction.
+ <literal role="stmt" condition="commit">BEGIN</literal> and
+ <literal role="stmt" condition="commit">BEGIN WORK</literal> are
+ supported as aliases of
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> for initiating a transaction.
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> is standard SQL syntax and is the
+ recommended way to start an ad-hoc transaction.
</para>
<important>
@@ -148,17 +162,19 @@
Many APIs used for writing MySQL client applications (such as
JDBC) provide their own methods for starting transactions that
can (and sometimes should) be used instead of sending a
- <literal role="stmt" condition="commit">START TRANSACTION</literal> statement from the client.
- See <xref linkend="connectors-apis"/>, or the documentation for
- your API, for more information.
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> statement from the client. See
+ <xref linkend="connectors-apis"/>, or the documentation for your
+ API, for more information.
</para>
</important>
<para>
- The <literal role="stmt" condition="commit">BEGIN</literal> statement differs from the use of the
- <literal>BEGIN</literal> keyword that starts a <literal>BEGIN ...
- END</literal> compound statement. The latter does not begin a
- transaction. See <xref linkend="begin-end"/>.
+ The <literal role="stmt" condition="commit">BEGIN</literal>
+ statement differs from the use of the <literal>BEGIN</literal>
+ keyword that starts a <literal>BEGIN ... END</literal> compound
+ statement. The latter does not begin a transaction. See
+ <xref linkend="begin-end"/>.
</para>
<para>
@@ -173,7 +189,8 @@
The <literal>WITH CONSISTENT SNAPSHOT</literal> clause starts a
consistent read for storage engines that are capable of it. This
applies only to <literal>InnoDB</literal>. The effect is the same
- as issuing a <literal role="stmt" condition="commit">START TRANSACTION</literal> followed by a
+ as issuing a <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> followed by a
<literal role="stmt">SELECT</literal> from any
<literal>InnoDB</literal> table. See
<xref linkend="innodb-consistent-read"/>. The <literal>WITH
@@ -238,8 +255,10 @@
<listitem>
<para>
- If you issue a <literal role="stmt" condition="commit">ROLLBACK</literal> statement after
- updating a non-transactional table within a transaction, an
+ If you issue a
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement after updating a non-transactional table within a
+ transaction, an
<literal>ER_WARNING_NOT_COMPLETE_ROLLBACK</literal> warning
occurs. Changes to transaction-safe tables are rolled back,
but not changes to non-transaction-safe tables.
@@ -250,13 +269,15 @@
<para>
Each transaction is stored in the binary log in one chunk, upon
- <literal role="stmt">COMMIT</literal>. Transactions that are rolled back are
- not logged. (<emphasis role="bold">Exception</emphasis>:
- Modifications to non-transactional tables cannot be rolled back.
- If a transaction that is rolled back includes modifications to
- non-transactional tables, the entire transaction is logged with a
- <literal role="stmt" condition="commit">ROLLBACK</literal> statement at the end to ensure that
- modifications to the non-transactional tables are replicated.) See
+ <literal role="stmt">COMMIT</literal>. Transactions that are
+ rolled back are not logged.
+ (<emphasis role="bold">Exception</emphasis>: Modifications to
+ non-transactional tables cannot be rolled back. If a transaction
+ that is rolled back includes modifications to non-transactional
+ tables, the entire transaction is logged with a
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement at the end to ensure that modifications to the
+ non-transactional tables are replicated.) See
<xref linkend="binary-log"/>.
</para>
@@ -272,7 +293,8 @@
an error occurs). Because of this, <literal role="stmt">SHOW
PROCESSLIST</literal> displays <literal>Rolling back</literal> in
the <literal>State</literal> column for the session, not only for
- explicit rollbacks performed with the <literal role="stmt" condition="commit">ROLLBACK</literal>
+ explicit rollbacks performed with the
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
statement but also for implicit rollbacks.
</para>
@@ -294,7 +316,9 @@
statements. If you issue a statement early in a transaction that
cannot be rolled back, and then another statement later fails, the
full effect of the transaction cannot be rolled back in such cases
- by issuing a <literal role="stmt" condition="commit">ROLLBACK</literal> statement.
+ by issuing a
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement.
</para>
</section>
@@ -306,7 +330,8 @@
<para>
The statements listed in this section (and any synonyms for them)
implicitly end a transaction, as if you had done a
- <literal role="stmt">COMMIT</literal> before executing the statement.
+ <literal role="stmt">COMMIT</literal> before executing the
+ statement.
</para>
<itemizedlist>
@@ -352,7 +377,8 @@
<para>
The <literal role="stmt">CREATE TABLE</literal> statement in
<literal>InnoDB</literal> is processed as a single
- transaction. This means that a <literal role="stmt" condition="commit">ROLLBACK</literal>
+ transaction. This means that a
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
from the user does not undo <literal role="stmt">CREATE
TABLE</literal> statements the user made during that
transaction.
@@ -398,10 +424,12 @@
<listitem>
<para>
<emphasis role="bold">Transaction-control and locking
- statements.</emphasis> <literal role="stmt" condition="commit">BEGIN</literal>,
+ statements.</emphasis>
+ <literal role="stmt" condition="commit">BEGIN</literal>,
<literal role="stmt">LOCK TABLES</literal>, <literal>SET
AUTOCOMMIT=1</literal> (if the value is not already 1),
- <literal role="stmt" condition="commit">START TRANSACTION</literal>,
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal>,
<literal role="stmt" condition="lock-tables">UNLOCK
TABLES</literal>.
</para>
@@ -421,8 +449,8 @@
<para>
Transactions cannot be nested. This is a consequence of the
implicit commit performed for any current transaction when you
- issue a <literal role="stmt" condition="commit">START TRANSACTION</literal> statement or one
- of its synonyms.
+ issue a <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> statement or one of its synonyms.
</para>
<para>
@@ -432,11 +460,11 @@
</para>
<para>
- The <literal role="stmt" condition="commit">BEGIN</literal> statement differs from the use of
- the <literal>BEGIN</literal> keyword that starts a
- <literal>BEGIN ... END</literal> compound statement. The
- latter does not cause an implicit commit. See
- <xref linkend="begin-end"/>.
+ The <literal role="stmt" condition="commit">BEGIN</literal>
+ statement differs from the use of the <literal>BEGIN</literal>
+ keyword that starts a <literal>BEGIN ... END</literal>
+ compound statement. The latter does not cause an implicit
+ commit. See <xref linkend="begin-end"/>.
</para>
</listitem>
@@ -473,7 +501,8 @@
<section id="savepoints">
- <title><literal role="stmt">SAVEPOINT</literal> and <literal role="stmt" condition="commit">ROLLBACK TO
+ <title><literal role="stmt">SAVEPOINT</literal> and
+ <literal role="stmt" condition="commit">ROLLBACK TO
SAVEPOINT</literal> Syntax</title>
<indexterm>
@@ -508,40 +537,43 @@
<para>
<literal>InnoDB</literal> supports the SQL statements
- <literal role="stmt">SAVEPOINT</literal>, <literal role="stmt" condition="commit">ROLLBACK TO
- SAVEPOINT</literal>, <literal role="stmt" condition="commit">RELEASE SAVEPOINT</literal> and the
- optional <literal>WORK</literal> keyword for
+ <literal role="stmt">SAVEPOINT</literal>,
+ <literal role="stmt" condition="commit">ROLLBACK TO
+ SAVEPOINT</literal>,
+ <literal role="stmt" condition="commit">RELEASE
+ SAVEPOINT</literal> and the optional <literal>WORK</literal>
+ keyword for
<literal role="stmt" condition="commit">ROLLBACK</literal>.
</para>
<remark role="help-description-end"/>
<para>
- The <literal role="stmt">SAVEPOINT</literal> statement sets a named
- transaction savepoint with a name of
+ The <literal role="stmt">SAVEPOINT</literal> statement sets a
+ named transaction savepoint with a name of
<replaceable>identifier</replaceable>. If the current transaction
has a savepoint with the same name, the old savepoint is deleted
and a new one is set.
</para>
<para>
- The <literal role="stmt" condition="commit">ROLLBACK TO SAVEPOINT</literal> statement rolls back
- a transaction to the named savepoint without terminating the
- transaction. Modifications that the current transaction made to
- rows after the savepoint was set are undone in the rollback, but
- <literal>InnoDB</literal> does <emphasis>not</emphasis> release
- the row locks that were stored in memory after the savepoint.
- (Note that for a new inserted row, the lock information is carried
- by the transaction ID stored in the row; the lock is not
- separately stored in memory. In this case, the row lock is
- released in the undo.) Savepoints that were set at a later time
- than the named savepoint are deleted.
+ The <literal role="stmt" condition="commit">ROLLBACK TO
+ SAVEPOINT</literal> statement rolls back a transaction to the
+ named savepoint without terminating the transaction. Modifications
+ that the current transaction made to rows after the savepoint was
+ set are undone in the rollback, but <literal>InnoDB</literal> does
+ <emphasis>not</emphasis> release the row locks that were stored in
+ memory after the savepoint. (Note that for a new inserted row, the
+ lock information is carried by the transaction ID stored in the
+ row; the lock is not separately stored in memory. In this case,
+ the row lock is released in the undo.) Savepoints that were set at
+ a later time than the named savepoint are deleted.
</para>
<para>
- If the <literal role="stmt" condition="commit">ROLLBACK TO SAVEPOINT</literal> statement returns
- the following error, it means that no savepoint with the specified
- name exists:
+ If the <literal role="stmt" condition="commit">ROLLBACK TO
+ SAVEPOINT</literal> statement returns the following error, it
+ means that no savepoint with the specified name exists:
</para>
<programlisting>
@@ -549,16 +581,17 @@
</programlisting>
<para>
- The <literal role="stmt" condition="commit">RELEASE SAVEPOINT</literal> statement removes the
- named savepoint from the set of savepoints of the current
- transaction. No commit or rollback occurs. It is an error if the
- savepoint does not exist.
+ The <literal role="stmt" condition="commit">RELEASE
+ SAVEPOINT</literal> statement removes the named savepoint from the
+ set of savepoints of the current transaction. No commit or
+ rollback occurs. It is an error if the savepoint does not exist.
</para>
<para>
All savepoints of the current transaction are deleted if you
execute a <literal role="stmt">COMMIT</literal>, or a
- <literal role="stmt" condition="commit">ROLLBACK</literal> that does not name a savepoint.
+ <literal role="stmt" condition="commit">ROLLBACK</literal> that
+ does not name a savepoint.
</para>
<para>
@@ -709,7 +742,8 @@
<listitem>
<para>
- Beginning a transaction (for example, with <literal role="stmt" condition="commit">START
+ Beginning a transaction (for example, with
+ <literal role="stmt" condition="commit">START
TRANSACTION</literal>) implicitly performs an
<literal role="stmt" condition="lock-tables">UNLOCK
TABLES</literal>. (Additional information about the
@@ -941,7 +975,8 @@
<listitem>
<para>
- Beginning a transaction (for example, with <literal role="stmt" condition="commit">START
+ Beginning a transaction (for example, with
+ <literal role="stmt" condition="commit">START
TRANSACTION</literal>) implicitly commits any current
transaction and releases existing locks.
</para>
@@ -962,7 +997,8 @@
<literal role="stmt" condition="lock-tables">UNLOCK
TABLES</literal> with transactional tables, such as
<literal>InnoDB</literal> tables, is to begin a transaction
- with <literal>SET AUTOCOMMIT = 0</literal> (not <literal role="stmt" condition="commit">START
+ with <literal>SET AUTOCOMMIT = 0</literal> (not
+ <literal role="stmt" condition="commit">START
TRANSACTION</literal>) followed by <literal role="stmt">LOCK
TABLES</literal>, and to not call
<literal role="stmt" condition="lock-tables">UNLOCK
@@ -986,7 +1022,8 @@
<listitem>
<para>
- <literal role="stmt" condition="commit">ROLLBACK</literal> does not release table locks.
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ does not release table locks.
</para>
</listitem>
@@ -1922,7 +1959,8 @@
START</literal> has been issued to begin an XA transaction, a
local transaction cannot be started until the XA transaction has
been committed or rolled back. Conversely, if a local
- transaction has been started with <literal role="stmt" condition="commit">START
+ transaction has been started with
+ <literal role="stmt" condition="commit">START
TRANSACTION</literal>, no XA statements can be used until the
transaction has been committed or rolled back.
</para>
Modified: trunk/refman-5.1/storage-engines.xml
===================================================================
--- trunk/refman-5.1/storage-engines.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.1/storage-engines.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 5, Lines Deleted: 4; 1061 bytes
@@ -749,15 +749,16 @@
<listitem>
<para>
You can combine many statements and accept them all at the
- same time with the <literal role="stmt">COMMIT</literal> statement (if
- autocommit is disabled).
+ same time with the <literal role="stmt">COMMIT</literal>
+ statement (if autocommit is disabled).
</para>
</listitem>
<listitem>
<para>
- You can execute <literal role="stmt" condition="commit">ROLLBACK</literal> to ignore your
- changes (if autocommit is disabled).
+ You can execute
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ to ignore your changes (if autocommit is disabled).
</para>
</listitem>
Modified: trunk/refman-5.1/stored-programs-views.xml
===================================================================
--- trunk/refman-5.1/stored-programs-views.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.1/stored-programs-views.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 2, Lines Added: 19, Lines Deleted: 14; 3076 bytes
@@ -854,17 +854,20 @@
procedure execution are replicated correctly. That is, the
server logs those statements within the procedure that
actually execute and modify data, and also logs
- <literal role="stmt" condition="commit">BEGIN</literal>, <literal role="stmt">COMMIT</literal>, and
- <literal role="stmt" condition="commit">ROLLBACK</literal> statements as necessary. For
- example, if a procedure updates only transactional tables
- and is executed within a transaction that is rolled back,
- those updates are not logged. If the procedure occurs
- within a committed transaction, <literal role="stmt" condition="commit">BEGIN</literal>
- and <literal role="stmt">COMMIT</literal> statements are logged with
- the updates. For a procedure that executes within a
- rolled-back transaction, its statements are logged using
- the same rules that would apply if the statements were
- executed in standalone fashion:
+ <literal role="stmt" condition="commit">BEGIN</literal>,
+ <literal role="stmt">COMMIT</literal>, and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statements as necessary. For example, if a procedure
+ updates only transactional tables and is executed within a
+ transaction that is rolled back, those updates are not
+ logged. If the procedure occurs within a committed
+ transaction,
+ <literal role="stmt" condition="commit">BEGIN</literal>
+ and <literal role="stmt">COMMIT</literal> statements are
+ logged with the updates. For a procedure that executes
+ within a rolled-back transaction, its statements are
+ logged using the same rules that would apply if the
+ statements were executed in standalone fashion:
</para>
<itemizedlist>
@@ -886,9 +889,11 @@
<para>
Updates to a mix of transactional and
non-transactional tables are logged surrounded by
- <literal role="stmt" condition="commit">BEGIN</literal> and
- <literal role="stmt" condition="commit">ROLLBACK</literal> so that slaves will make
- the same changes and rollbacks as on the master.
+ <literal role="stmt" condition="commit">BEGIN</literal>
+ and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ so that slaves will make the same changes and
+ rollbacks as on the master.
</para>
</listitem>
Modified: trunk/refman-5.1/triggers.xml
===================================================================
--- trunk/refman-5.1/triggers.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.1/triggers.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 4, Lines Deleted: 3; 898 bytes
@@ -339,9 +339,10 @@
<listitem>
<para>
The trigger cannot use statements that explicitly or
- implicitly begin or end a transaction such as <literal role="stmt" condition="commit">START
- TRANSACTION</literal>, <literal role="stmt">COMMIT</literal>, or
- <literal role="stmt" condition="commit">ROLLBACK</literal>.
+ implicitly begin or end a transaction such as
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal>, <literal role="stmt">COMMIT</literal>,
+ or <literal role="stmt" condition="commit">ROLLBACK</literal>.
</para>
</listitem>
Modified: trunk/refman-5.1-maria/se-maria-core.xml
===================================================================
--- trunk/refman-5.1-maria/se-maria-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.1-maria/se-maria-core.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 3, Lines Added: 6, Lines Deleted: 4; 1611 bytes
@@ -417,8 +417,8 @@
<literal>at_flush</literal> — the logs will be
removed (deleted from disk) only when they have been
marked 'free' (i.e. there are no pending transactions),
- and a <literal role="stmt" condition="flush">FLUSH LOGS</literal> statement has been
- executed.
+ and a <literal role="stmt" condition="flush">FLUSH
+ LOGS</literal> statement has been executed.
</para>
</listitem>
@@ -845,7 +845,8 @@
<para>
You can determine the list of current log files using the
- statement <literal role="stmt" condition="show-engine">SHOW ENGINE MARIA LOGS</literal>:
+ statement <literal role="stmt" condition="show-engine">SHOW ENGINE
+ MARIA LOGS</literal>:
</para>
<programlisting>mysql> SHOW ENGINE MARIA LOGS;
@@ -952,7 +953,8 @@
<para>
In <literal>at_flush</literal> mode, the log files are only
- deleted when you execute the <literal role="stmt" condition="flush">FLUSH LOGS</literal>
+ deleted when you execute the
+ <literal role="stmt" condition="flush">FLUSH LOGS</literal>
statement. Issuing this statement will delete the logs that have
the 'free' status, and therefore will not affect logs with
outstanding transactions or events.
Modified: trunk/refman-5.1-maria/sql-syntax-server-administration.xml
===================================================================
--- trunk/refman-5.1-maria/sql-syntax-server-administration.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.1-maria/sql-syntax-server-administration.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 24, Lines Added: 92, Lines Deleted: 72; 16660 bytes
@@ -635,10 +635,10 @@
<entry>Enables use of <literal>CHANGE MASTER</literal>,
<literal role="stmt">KILL</literal>,
<literal role="stmt">PURGE BINARY LOGS</literal>, and
- <literal role="stmt" condition="set-option">SET GLOBAL</literal> statements, the
- <command>mysqladmin debug</command> command; allows you
- to connect (once) even if
- <literal>max_connections</literal> is reached</entry>
+ <literal role="stmt" condition="set-option">SET
+ GLOBAL</literal> statements, the <command>mysqladmin
+ debug</command> command; allows you to connect (once)
+ even if <literal>max_connections</literal> is reached</entry>
</row>
<row>
<entry><literal>TRIGGER</literal></entry>
@@ -3516,8 +3516,9 @@
<listitem>
<para>
- <literal role="stmt" condition="set-transaction">SET TRANSACTION ISOLATION LEVEL</literal> sets the
- isolation level for transaction processing. See
+ <literal role="stmt" condition="set-transaction">SET
+ TRANSACTION ISOLATION LEVEL</literal> sets the isolation level
+ for transaction processing. See
<xref linkend="set-transaction"/>.
</para>
</listitem>
@@ -3662,16 +3663,18 @@
corresponding session variable only for clients that connect after
the change. The global variable change does not affect the session
variable for any client that is currently connected (not even that
- of the client that issues the <literal role="stmt" condition="set-option">SET GLOBAL</literal>
+ of the client that issues the
+ <literal role="stmt" condition="set-option">SET GLOBAL</literal>
statement).
</para>
<para>
To prevent incorrect usage, MySQL produces an error if you use
- <literal role="stmt" condition="set-option">SET GLOBAL</literal> with a variable that can only be
- used with <literal role="stmt" condition="set-option">SET SESSION</literal> or if you do not specify
- <literal>GLOBAL</literal> (or <literal>@@global.</literal>) when
- setting a global variable.
+ <literal role="stmt" condition="set-option">SET GLOBAL</literal>
+ with a variable that can only be used with
+ <literal role="stmt" condition="set-option">SET SESSION</literal>
+ or if you do not specify <literal>GLOBAL</literal> (or
+ <literal>@@global.</literal>) when setting a global variable.
</para>
<para>
@@ -4290,8 +4293,9 @@
<remark role="help-description-end"/>
<para>
- <literal role="stmt" condition="show-binary-logs">SHOW MASTER LOGS</literal> is equivalent to
- <literal role="stmt">SHOW BINARY LOGS</literal>.
+ <literal role="stmt" condition="show-binary-logs">SHOW MASTER
+ LOGS</literal> is equivalent to <literal role="stmt">SHOW BINARY
+ LOGS</literal>.
</para>
</section>
@@ -5228,13 +5232,15 @@
<para>
Older (and now deprecated) synonyms are
<literal role="stmt">SHOW INNODB STATUS</literal> for
- <literal role="stmt" condition="show-engine">SHOW ENGINE INNODB STATUS</literal> and <literal>SHOW
- MUTEX STATUS</literal> for <literal role="stmt" condition="show-engine">SHOW ENGINE INNODB
+ <literal role="stmt" condition="show-engine">SHOW ENGINE INNODB
+ STATUS</literal> and <literal>SHOW MUTEX STATUS</literal> for
+ <literal role="stmt" condition="show-engine">SHOW ENGINE INNODB
MUTEX</literal>.
</para>
<para>
- In MySQL &previous-series;, <literal role="stmt" condition="show-engine">SHOW ENGINE INNODB
+ In MySQL &previous-series;,
+ <literal role="stmt" condition="show-engine">SHOW ENGINE INNODB
MUTEX</literal> is invoked as <literal>SHOW MUTEX
STATUS</literal>. The latter statement displays similar
information but in a somewhat different output format.
@@ -5248,9 +5254,9 @@
</para>
<para>
- <literal role="stmt" condition="show-engine">SHOW ENGINE INNODB STATUS</literal> displays extensive
- information about the state of the <literal>InnoDB</literal>
- storage engine.
+ <literal role="stmt" condition="show-engine">SHOW ENGINE INNODB
+ STATUS</literal> displays extensive information about the state
+ of the <literal>InnoDB</literal> storage engine.
</para>
<para>
@@ -5260,9 +5266,10 @@
</para>
<para>
- <literal role="stmt" condition="show-engine">SHOW ENGINE INNODB MUTEX</literal> displays
- <literal>InnoDB</literal> mutex statistics. From MySQL 5.1.2 to
- 5.1.14, the statement displays the following output fields:
+ <literal role="stmt" condition="show-engine">SHOW ENGINE INNODB
+ MUTEX</literal> displays <literal>InnoDB</literal> mutex
+ statistics. From MySQL 5.1.2 to 5.1.14, the statement displays
+ the following output fields:
</para>
<itemizedlist>
@@ -6537,8 +6544,8 @@
<para>
In MySQL ¤t-series;, this is a deprecated synonym for
- <literal role="stmt" condition="show-engine">SHOW ENGINE INNODB STATUS</literal>. See
- <xref linkend="show-engine"/>.
+ <literal role="stmt" condition="show-engine">SHOW ENGINE INNODB
+ STATUS</literal>. See <xref linkend="show-engine"/>.
</para>
<remark role="help-description-end"/>
@@ -9348,12 +9355,12 @@
<para>
If the server is writing error output to a named file (for
example, if it was started with the
- <option>--log-error</option> option), <literal role="stmt" condition="flush">FLUSH
- LOGS</literal> causes it to rename the current error log
- file with a suffix of <literal>-old</literal> and create a
- new empty log file. No renaming occurs if the server is not
- writing to a named file (for example, if it is writing
- errors to the console).
+ <option>--log-error</option> option),
+ <literal role="stmt" condition="flush">FLUSH LOGS</literal>
+ causes it to rename the current error log file with a suffix
+ of <literal>-old</literal> and create a new empty log file.
+ No renaming occurs if the server is not writing to a named
+ file (for example, if it is writing errors to the console).
</para>
</listitem>
@@ -9361,7 +9368,8 @@
<para>
<literal>MASTER</literal> (<emphasis>DEPRECATED</emphasis>).
Deletes all binary logs, resets the binary log index file
- and creates a new binary log. <literal role="stmt" condition="flush">FLUSH
+ and creates a new binary log.
+ <literal role="stmt" condition="flush">FLUSH
MASTER</literal> is deprecated in favor of
<literal role="stmt">RESET MASTER</literal>, and is
supported for backward compatibility only. See
@@ -9394,7 +9402,8 @@
so for a server that executes many instances of the
statements that cause caching, there will be an increase in
memory use. This cached memory can be freed with
- <literal role="stmt" condition="flush">FLUSH PRIVILEGES</literal>.
+ <literal role="stmt" condition="flush">FLUSH
+ PRIVILEGES</literal>.
</para>
</listitem>
@@ -9405,8 +9414,9 @@
<para>
Defragment the query cache to better utilize its memory.
- <literal role="stmt" condition="flush">FLUSH QUERY CACHE</literal> does not remove any
- queries from the cache, unlike <literal role="stmt" condition="flush">FLUSH
+ <literal role="stmt" condition="flush">FLUSH QUERY
+ CACHE</literal> does not remove any queries from the cache,
+ unlike <literal role="stmt" condition="flush">FLUSH
TABLES</literal> or <literal>RESET QUERY CACHE</literal>.
</para>
</listitem>
@@ -9416,10 +9426,10 @@
<literal>SLAVE</literal> (<emphasis>DEPRECATED</emphasis>).
Resets all replication slave parameters, including relay log
files and replication position in the master's binary logs.
- <literal role="stmt" condition="flush">FLUSH SLAVE</literal> is deprecated in favor of
- <literal role="stmt">RESET SLAVE</literal>, and is supported
- for backward compatibility only. See
- <xref linkend="reset-slave"/>.
+ <literal role="stmt" condition="flush">FLUSH SLAVE</literal>
+ is deprecated in favor of <literal role="stmt">RESET
+ SLAVE</literal>, and is supported for backward compatibility
+ only. See <xref linkend="reset-slave"/>.
</para>
</listitem>
@@ -9454,9 +9464,10 @@
When no tables are named, closes all open tables, forces all
tables in use to be closed, and flushes the query cache.
With one or more table names, flushes only the given tables.
- <literal role="stmt" condition="flush">FLUSH TABLES</literal> also removes all query
- results from the query cache, like the <literal>RESET QUERY
- CACHE</literal> statement.
+ <literal role="stmt" condition="flush">FLUSH
+ TABLES</literal> also removes all query results from the
+ query cache, like the <literal>RESET QUERY CACHE</literal>
+ statement.
</para>
</listitem>
@@ -9476,10 +9487,10 @@
</para>
<para>
- <literal role="stmt" condition="flush">FLUSH TABLES WITH READ LOCK</literal> acquires a
- global read lock and not table locks, so it is not subject
- to the same behavior as <literal role="stmt">LOCK
- TABLES</literal> and
+ <literal role="stmt" condition="flush">FLUSH TABLES WITH
+ READ LOCK</literal> acquires a global read lock and not
+ table locks, so it is not subject to the same behavior as
+ <literal role="stmt">LOCK TABLES</literal> and
<literal role="stmt" condition="lock-tables">UNLOCK
TABLES</literal> with respect to table locking and implicit
commits:
@@ -9495,7 +9506,8 @@
locked with <literal role="stmt">LOCK TABLES</literal>.
The commit does not occur for
<literal role="stmt" condition="lock-tables">UNLOCK
- TABLES</literal> following <literal role="stmt" condition="flush">FLUSH TABLES WITH
+ TABLES</literal> following
+ <literal role="stmt" condition="flush">FLUSH TABLES WITH
READ LOCK</literal> because the latter statement does
not acquire table locks.
</para>
@@ -9508,8 +9520,9 @@
released, as though you had executed
<literal role="stmt" condition="lock-tables">UNLOCK
TABLES</literal>. Beginning a transaction does not
- release a global read lock acquired with <literal role="stmt" condition="flush">FLUSH
- TABLES WITH READ LOCK</literal>.
+ release a global read lock acquired with
+ <literal role="stmt" condition="flush">FLUSH TABLES WITH
+ READ LOCK</literal>.
</para>
</listitem>
@@ -9524,7 +9537,8 @@
<para>
Resets all per-hour user resources to zero. This enables
clients that have reached their hourly connection, query, or
- update limits to resume activity immediately. <literal role="stmt" condition="flush">FLUSH
+ update limits to resume activity immediately.
+ <literal role="stmt" condition="flush">FLUSH
USER_RESOURCES</literal> does not apply to the limit on
maximum simultaneous connections. See
<xref linkend="grant"/>.
@@ -9550,11 +9564,13 @@
<note>
<para>
- <literal role="stmt" condition="flush">FLUSH LOGS</literal>, <literal role="stmt" condition="flush">FLUSH
- MASTER</literal>, <literal role="stmt" condition="flush">FLUSH SLAVE</literal>, and
- <literal role="stmt" condition="flush">FLUSH TABLES WITH READ LOCK</literal> are not written
- to the binary log in any case because they would cause
- problems if replicated to a slave.
+ <literal role="stmt" condition="flush">FLUSH LOGS</literal>,
+ <literal role="stmt" condition="flush">FLUSH MASTER</literal>,
+ <literal role="stmt" condition="flush">FLUSH SLAVE</literal>,
+ and <literal role="stmt" condition="flush">FLUSH TABLES WITH
+ READ LOCK</literal> are not written to the binary log in any
+ case because they would cause problems if replicated to a
+ slave.
</para>
</note>
@@ -9624,7 +9640,8 @@
<listitem>
<para>
- <literal role="stmt" condition="kill">KILL CONNECTION</literal> is the same as
+ <literal role="stmt" condition="kill">KILL
+ CONNECTION</literal> is the same as
<literal role="stmt">KILL</literal> with no modifier: It
terminates the connection associated with the given
<replaceable>thread_id</replaceable>.
@@ -9633,9 +9650,9 @@
<listitem>
<para>
- <literal role="stmt" condition="kill">KILL QUERY</literal> terminates the statement that
- the connection is currently executing, but leaves the
- connection itself intact.
+ <literal role="stmt" condition="kill">KILL QUERY</literal>
+ terminates the statement that the connection is currently
+ executing, but leaves the connection itself intact.
</para>
</listitem>
@@ -9752,7 +9769,8 @@
<section id="load-index">
- <title><literal role="stmt" condition="load-index">LOAD INDEX INTO CACHE</literal> Syntax</title>
+ <title><literal role="stmt" condition="load-index">LOAD INDEX INTO
+ CACHE</literal> Syntax</title>
<remark role="help-topic" condition="LOAD INDEX"/>
@@ -9775,14 +9793,15 @@
<remark role="help-description-begin"/>
<para>
- The <literal role="stmt" condition="load-index">LOAD INDEX INTO CACHE</literal> statement preloads
- a table index into the key cache to which it has been assigned
- by an explicit <literal role="stmt">CACHE INDEX</literal>
- statement, or into the default key cache otherwise.
- <literal role="stmt" condition="load-index">LOAD INDEX INTO CACHE</literal> is used only for
- <literal>MyISAM</literal> tables. It is not supported for tables
- having user-defined partitioning (see
- <xref linkend="partitioning-limitations"/>.)
+ The <literal role="stmt" condition="load-index">LOAD INDEX INTO
+ CACHE</literal> statement preloads a table index into the key
+ cache to which it has been assigned by an explicit
+ <literal role="stmt">CACHE INDEX</literal> statement, or into
+ the default key cache otherwise.
+ <literal role="stmt" condition="load-index">LOAD INDEX INTO
+ CACHE</literal> is used only for <literal>MyISAM</literal>
+ tables. It is not supported for tables having user-defined
+ partitioning (see <xref linkend="partitioning-limitations"/>.)
</para>
<para>
@@ -9814,11 +9833,12 @@
</para>
<para>
- The syntax of <literal role="stmt" condition="load-index">LOAD INDEX INTO CACHE</literal> enables
- you to specify that only particular indexes from a table should
- be preloaded. The current implementation preloads all the
- table's indexes into the cache, so there is no reason to specify
- anything other than the table name.
+ The syntax of <literal role="stmt" condition="load-index">LOAD
+ INDEX INTO CACHE</literal> enables you to specify that only
+ particular indexes from a table should be preloaded. The current
+ implementation preloads all the table's indexes into the cache,
+ so there is no reason to specify anything other than the table
+ name.
</para>
<para>
Modified: trunk/refman-5.1-maria/storage-engines.xml
===================================================================
--- trunk/refman-5.1-maria/storage-engines.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-5.1-maria/storage-engines.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 5, Lines Deleted: 4; 1079 bytes
@@ -738,15 +738,16 @@
<listitem>
<para>
You can combine many statements and accept them all at the
- same time with the <literal role="stmt">COMMIT</literal> statement (if
- autocommit is disabled).
+ same time with the <literal role="stmt">COMMIT</literal>
+ statement (if autocommit is disabled).
</para>
</listitem>
<listitem>
<para>
- You can execute <literal role="stmt" condition="commit">ROLLBACK</literal> to ignore your
- changes (if autocommit is disabled).
+ You can execute
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ to ignore your changes (if autocommit is disabled).
</para>
</listitem>
Modified: trunk/refman-6.0/apis-c.xml
===================================================================
--- trunk/refman-6.0/apis-c.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-6.0/apis-c.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 9, Lines Deleted: 8; 1535 bytes
@@ -1693,14 +1693,15 @@
<para>
This command resets the state as if one had done a new connect.
(See <xref linkend="auto-reconnect"/>.) It always performs a
- <literal role="stmt" condition="commit">ROLLBACK</literal> of any active transactions, closes
- and drops all temporary tables, and unlocks all locked tables.
- Session system variables are reset to the values of the
- corresponding global system variables. Prepared statements are
- released and <literal role="stmt">HANDLER</literal> variables
- are closed. Locks acquired with
- <literal role="func">GET_LOCK()</literal> are released. These
- effects occur even if the user didn't change.
+ <literal role="stmt" condition="commit">ROLLBACK</literal> of
+ any active transactions, closes and drops all temporary tables,
+ and unlocks all locked tables. Session system variables are
+ reset to the values of the corresponding global system
+ variables. Prepared statements are released and
+ <literal role="stmt">HANDLER</literal> variables are closed.
+ Locks acquired with <literal role="func">GET_LOCK()</literal>
+ are released. These effects occur even if the user didn't
+ change.
</para>
<para>
Modified: trunk/refman-6.0/dba-core.xml
===================================================================
--- trunk/refman-6.0/dba-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-6.0/dba-core.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 5, Lines Added: 45, Lines Deleted: 37; 7472 bytes
@@ -4401,28 +4401,31 @@
<para>
If the value is 0 (the default),
<literal role="stmt">COMMIT</literal> and
- <literal role="stmt" condition="commit">ROLLBACK</literal> are unaffected.
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ are unaffected.
</para>
</listitem>
<listitem>
<para>
- If the value is 1, <literal role="stmt">COMMIT</literal> and
- <literal role="stmt" condition="commit">ROLLBACK</literal> are equivalent to
- <literal>COMMIT AND CHAIN</literal> and
- <literal>ROLLBACK AND CHAIN</literal>, respectively. (A
- new transaction starts immediately with the same
+ If the value is 1, <literal role="stmt">COMMIT</literal>
+ and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ are equivalent to <literal>COMMIT AND CHAIN</literal>
+ and <literal>ROLLBACK AND CHAIN</literal>, respectively.
+ (A new transaction starts immediately with the same
isolation level as the just-terminated transaction.)
</para>
</listitem>
<listitem>
<para>
- If the value is 2, <literal role="stmt">COMMIT</literal> and
- <literal role="stmt" condition="commit">ROLLBACK</literal> are equivalent to
- <literal>COMMIT RELEASE</literal> and <literal>ROLLBACK
- RELEASE</literal>, respectively. (The server disconnects
- after terminating the transaction.)
+ If the value is 2, <literal role="stmt">COMMIT</literal>
+ and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ are equivalent to <literal>COMMIT RELEASE</literal> and
+ <literal>ROLLBACK RELEASE</literal>, respectively. (The
+ server disconnects after terminating the transaction.)
</para>
</listitem>
@@ -8537,15 +8540,18 @@
<para>
Set the autocommit mode. If set to 1, all changes to a table
take effect immediately. If set to 0 you have to use
- <literal role="stmt">COMMIT</literal> to accept a transaction or
- <literal role="stmt" condition="commit">ROLLBACK</literal> to cancel it. By default, client
- connections begin with <literal>AUTOCOMMIT</literal> set to
- 1. If you change <literal>AUTOCOMMIT</literal> mode from 0
- to 1, MySQL performs an automatic <literal role="stmt">COMMIT</literal>
+ <literal role="stmt">COMMIT</literal> to accept a
+ transaction or
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ to cancel it. By default, client connections begin with
+ <literal>AUTOCOMMIT</literal> set to 1. If you change
+ <literal>AUTOCOMMIT</literal> mode from 0 to 1, MySQL
+ performs an automatic <literal role="stmt">COMMIT</literal>
of any open transaction. Another way to begin a transaction
- is to use a <literal role="stmt" condition="commit">START TRANSACTION</literal> or
- <literal role="stmt" condition="commit">BEGIN</literal> statement. See
- <xref linkend="commit"/>.
+ is to use a <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> or
+ <literal role="stmt" condition="commit">BEGIN</literal>
+ statement. See <xref linkend="commit"/>.
</para>
</listitem>
@@ -10075,7 +10081,8 @@
</para>
<para>
- The number of internal <literal role="stmt">COMMIT</literal> statements.
+ The number of internal <literal role="stmt">COMMIT</literal>
+ statements.
</para>
</listitem>
@@ -14136,23 +14143,24 @@
<literal role="stmt">INSERT</literal>) that change transactional
tables such as <literal>BDB</literal> or
<literal>InnoDB</literal> tables are cached until a
- <literal role="stmt">COMMIT</literal> statement is received by the server.
- At that point, <command>mysqld</command> writes the entire
- transaction to the binary log before the
- <literal role="stmt">COMMIT</literal> is executed. When the thread that
- handles the transaction starts, it allocates a buffer of
- <literal>binlog_cache_size</literal> to buffer statements. If a
- statement is bigger than this, the thread opens a temporary file
- to store the transaction. The temporary file is deleted when the
- thread ends.
+ <literal role="stmt">COMMIT</literal> statement is received by
+ the server. At that point, <command>mysqld</command> writes the
+ entire transaction to the binary log before the
+ <literal role="stmt">COMMIT</literal> is executed. When the
+ thread that handles the transaction starts, it allocates a
+ buffer of <literal>binlog_cache_size</literal> to buffer
+ statements. If a statement is bigger than this, the thread opens
+ a temporary file to store the transaction. The temporary file is
+ deleted when the thread ends.
</para>
<para>
Modifications to non-transactional tables cannot be rolled back.
If a transaction that is rolled back includes modifications to
non-transactional tables, the entire transaction is logged with
- a <literal role="stmt" condition="commit">ROLLBACK</literal> statement at the end to ensure
- that the modifications to those tables are replicated.
+ a <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement at the end to ensure that the modifications to those
+ tables are replicated.
</para>
<para>
@@ -14205,12 +14213,12 @@
chance of an inconsistency between the table content and binary
log content in case of a crash. For example, if you are using
<literal>InnoDB</literal> tables and the MySQL server processes
- a <literal role="stmt">COMMIT</literal> statement, it writes the whole
- transaction to the binary log and then commits this transaction
- into <literal>InnoDB</literal>. If the server crashes between
- those two operations, the transaction is rolled back by
- <literal>InnoDB</literal> at restart but still exists in the
- binary log. To resolve this, you should set
+ a <literal role="stmt">COMMIT</literal> statement, it writes the
+ whole transaction to the binary log and then commits this
+ transaction into <literal>InnoDB</literal>. If the server
+ crashes between those two operations, the transaction is rolled
+ back by <literal>InnoDB</literal> at restart but still exists in
+ the binary log. To resolve this, you should set
<option>--innodb_support_xa</option> to 1. Although this option
is related to the support of XA transactions in InnoDB, it also
ensures that the binary log and InnoDB data files are
Modified: trunk/refman-6.0/errors-problems.xml
===================================================================
--- trunk/refman-6.0/errors-problems.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-6.0/errors-problems.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 3, Lines Added: 8, Lines Deleted: 7; 1715 bytes
@@ -4312,9 +4312,9 @@
<para>
If you receive the following message when trying to perform a
- <literal role="stmt" condition="commit">ROLLBACK</literal>, it means that one or more of the
- tables you used in the transaction do not support
- transactions:
+ <literal role="stmt" condition="commit">ROLLBACK</literal>, it
+ means that one or more of the tables you used in the
+ transaction do not support transactions:
</para>
<programlisting>
@@ -4323,7 +4323,8 @@
<para>
These non-transactional tables are not affected by the
- <literal role="stmt" condition="commit">ROLLBACK</literal> statement.
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement.
</para>
<para>
@@ -5181,9 +5182,9 @@
<para>
<literal role="stmt" condition="flush">FLUSH TABLES WITH
READ LOCK</literal> does not block
- <literal role="stmt">COMMIT</literal> if the server is running without
- binary logging, which may cause a problem (of consistency
- between tables) when doing a full backup.
+ <literal role="stmt">COMMIT</literal> if the server is
+ running without binary logging, which may cause a problem
+ (of consistency between tables) when doing a full backup.
</para>
</listitem>
Modified: trunk/refman-6.0/functions-core.xml
===================================================================
--- trunk/refman-6.0/functions-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-6.0/functions-core.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 6, Lines Deleted: 4; 1218 bytes
@@ -16877,10 +16877,12 @@
undefined. For transactional tables, if the statement is
rolled back due to an error, the value of
<literal role="func">LAST_INSERT_ID()</literal> is left
- undefined. For manual <literal role="stmt" condition="commit">ROLLBACK</literal>, the value
- of <literal role="func">LAST_INSERT_ID()</literal> is not
- restored to that before the transaction; it remains as it
- was at the point of the <literal role="stmt" condition="commit">ROLLBACK</literal>.
+ undefined. For manual
+ <literal role="stmt" condition="commit">ROLLBACK</literal>,
+ the value of <literal role="func">LAST_INSERT_ID()</literal>
+ is not restored to that before the transaction; it remains
+ as it was at the point of the
+ <literal role="stmt" condition="commit">ROLLBACK</literal>.
</para>
<para>
Modified: trunk/refman-6.0/introduction.xml
===================================================================
--- trunk/refman-6.0/introduction.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-6.0/introduction.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 4, Lines Added: 18, Lines Deleted: 15; 3407 bytes
@@ -458,7 +458,8 @@
Transactional locks acquired with
<literal role="stmt">LOCK TABLES</literal> are released
when the transaction ends, either explicitly with
- <literal role="stmt">COMMIT</literal> or <literal role="stmt" condition="commit">ROLLBACK</literal>,
+ <literal role="stmt">COMMIT</literal> or
+ <literal role="stmt" condition="commit">ROLLBACK</literal>,
or implicitly due to a statement that causes implicit
commit or because the connection ends.
<xref linkend="implicit-commit"/>, lists those statements
@@ -1665,13 +1666,13 @@
<para>
If your applications are written in a way that is
dependent on being able to call
- <literal role="stmt" condition="commit">ROLLBACK</literal> rather than
- <literal role="stmt">COMMIT</literal> in critical situations,
- transactions are more convenient. Transactions also ensure
- that unfinished updates or corrupting activities are not
- committed to the database; the server is given the
- opportunity to do an automatic rollback and your database
- is saved.
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ rather than <literal role="stmt">COMMIT</literal> in
+ critical situations, transactions are more convenient.
+ Transactions also ensure that unfinished updates or
+ corrupting activities are not committed to the database;
+ the server is given the opportunity to do an automatic
+ rollback and your database is saved.
</para>
<para>
@@ -1768,8 +1769,9 @@
<listitem>
<para>
- To avoid using <literal role="stmt" condition="commit">ROLLBACK</literal>, you can employ
- the following strategy:
+ To avoid using
+ <literal role="stmt" condition="commit">ROLLBACK</literal>,
+ you can employ the following strategy:
</para>
<orderedlist>
@@ -1892,11 +1894,12 @@
</indexterm>
In many cases, users have wanted <literal role="stmt">LOCK
- TABLES</literal> or <literal role="stmt" condition="commit">ROLLBACK</literal> for the
- purpose of managing unique identifiers. This can be
- handled much more efficiently without locking or rolling
- back by using an <literal>AUTO_INCREMENT</literal> column
- and either the
+ TABLES</literal> or
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ for the purpose of managing unique identifiers. This can
+ be handled much more efficiently without locking or
+ rolling back by using an <literal>AUTO_INCREMENT</literal>
+ column and either the
<literal role="func">LAST_INSERT_ID()</literal> SQL
function or the
<literal role="cfunc">mysql_insert_id()</literal> C API
Modified: trunk/refman-6.0/optimization.xml
===================================================================
--- trunk/refman-6.0/optimization.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-6.0/optimization.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 1; 702 bytes
@@ -7644,7 +7644,8 @@
<para>
To obtain faster insertions for transactional tables, you
- should use <literal role="stmt" condition="commit">START TRANSACTION</literal> and
+ should use <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> and
<literal role="stmt">COMMIT</literal> instead of
<literal role="stmt">LOCK TABLES</literal>.
</para>
Modified: trunk/refman-6.0/programs-client-core.xml
===================================================================
--- trunk/refman-6.0/programs-client-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-6.0/programs-client-core.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 2, Lines Added: 10, Lines Deleted: 8; 1719 bytes
@@ -6745,8 +6745,8 @@
<para>
Enclose the <literal role="stmt">INSERT</literal> statements
for each dumped table within <literal>SET
- AUTOCOMMIT=0</literal> and <literal role="stmt">COMMIT</literal>
- statements.
+ AUTOCOMMIT=0</literal> and
+ <literal role="stmt">COMMIT</literal> statements.
</para>
</listitem>
@@ -7155,12 +7155,14 @@
</para>
<para>
- This option issues a <literal role="stmt" condition="commit">BEGIN</literal> SQL statement
- before dumping data from the server. It is useful only with
- transactional tables such as <literal>InnoDB</literal>,
- because then it dumps the consistent state of the database
- at the time when <literal role="stmt" condition="commit">BEGIN</literal> was issued without
- blocking any applications.
+ This option issues a
+ <literal role="stmt" condition="commit">BEGIN</literal> SQL
+ statement before dumping data from the server. It is useful
+ only with transactional tables such as
+ <literal>InnoDB</literal>, because then it dumps the
+ consistent state of the database at the time when
+ <literal role="stmt" condition="commit">BEGIN</literal> was
+ issued without blocking any applications.
</para>
<para>
Modified: trunk/refman-6.0/replication-configuration-core.xml
===================================================================
--- trunk/refman-6.0/replication-configuration-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-6.0/replication-configuration-core.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 2; 726 bytes
@@ -455,8 +455,8 @@
<para>
For <literal>InnoDB</literal> tables, note that
<literal role="stmt" condition="flush">FLUSH TABLES WITH
- READ LOCK</literal> also blocks <literal role="stmt">COMMIT</literal>
- operations.
+ READ LOCK</literal> also blocks
+ <literal role="stmt">COMMIT</literal> operations.
</para>
<warning>
Modified: trunk/refman-6.0/replication-notes.xml
===================================================================
--- trunk/refman-6.0/replication-notes.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-6.0/replication-notes.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 2, Lines Added: 4, Lines Deleted: 3; 1572 bytes
@@ -1815,8 +1815,8 @@
can replicate an <literal>InnoDB</literal> master table as a
<literal>MyISAM</literal> slave table. However, if you do this,
there are problems if the slave is stopped in the middle of a
- <literal role="stmt" condition="commit">BEGIN</literal>/<literal role="stmt">COMMIT</literal> block because
- the slave restarts at the beginning of the
+ <literal role="stmt" condition="commit">BEGIN</literal>/<literal role="stmt">COMMIT</literal>
+ block because the slave restarts at the beginning of the
<literal role="stmt" condition="commit">BEGIN</literal> block.
</para>
@@ -1824,7 +1824,8 @@
In situations where transactions mix updates to transactional
and non-transactional tables, the order of statements in the
binary log is correct, and all needed statements are written to
- the binary log even in case of a <literal role="stmt" condition="commit">ROLLBACK</literal>.
+ the binary log even in case of a
+ <literal role="stmt" condition="commit">ROLLBACK</literal>.
However, when a second connection updates the non-transactional
table before the first connection's transaction is complete,
statements can be logged out of order, because the second
Modified: trunk/refman-6.0/se-falcon-core.xml
===================================================================
--- trunk/refman-6.0/se-falcon-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-6.0/se-falcon-core.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 3, Lines Deleted: 3; 858 bytes
@@ -1275,9 +1275,9 @@
All transactions on the database are logged and stored within a
separate log file. The log file is automatically flushed and the
changes written to disk when there is a
- <literal role="stmt">COMMIT</literal> command, when auto-commit is enabled,
- or automatically every 30 seconds when transactions are not
- being employed.
+ <literal role="stmt">COMMIT</literal> command, when auto-commit
+ is enabled, or automatically every 30 seconds when transactions
+ are not being employed.
</para>
</section>
Modified: trunk/refman-6.0/se-innodb-core.xml
===================================================================
--- trunk/refman-6.0/se-innodb-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-6.0/se-innodb-core.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 11, Lines Added: 55, Lines Deleted: 39; 9454 bytes
@@ -2165,10 +2165,12 @@
transactions, you can switch autocommit off with the SQL
statement <literal>SET AUTOCOMMIT = 0</literal> and end each
transaction with either <literal role="stmt">COMMIT</literal> or
- <literal role="stmt" condition="commit">ROLLBACK</literal>. If you want to leave autocommit on,
- you can begin your transactions within <literal role="stmt" condition="commit">START
+ <literal role="stmt" condition="commit">ROLLBACK</literal>. If
+ you want to leave autocommit on, you can begin your transactions
+ within <literal role="stmt" condition="commit">START
TRANSACTION</literal> and end them with
- <literal role="stmt">COMMIT</literal> or <literal role="stmt" condition="commit">ROLLBACK</literal>. The
+ <literal role="stmt">COMMIT</literal> or
+ <literal role="stmt" condition="commit">ROLLBACK</literal>. The
following example shows two transactions. The first is
committed; the second is rolled back.
</para>
@@ -2204,9 +2206,9 @@
<para>
In APIs such as PHP, Perl DBI, JDBC, ODBC, or the standard C
call interface of MySQL, you can send transaction control
- statements such as <literal role="stmt">COMMIT</literal> to the MySQL server
- as strings just like any other SQL statements such as
- <literal role="stmt">SELECT</literal> or
+ statements such as <literal role="stmt">COMMIT</literal> to the
+ MySQL server as strings just like any other SQL statements such
+ as <literal role="stmt">SELECT</literal> or
<literal role="stmt">INSERT</literal>. Some APIs also offer
separate special transaction commit and rollback functions or
methods.
@@ -4777,14 +4779,17 @@
<para>
If autocommit mode is disabled within a session with
<literal>SET AUTOCOMMIT = 0</literal>, the session always has a
- transaction open. An SQL <literal role="stmt">COMMIT</literal> or
- <literal role="stmt" condition="commit">ROLLBACK</literal> statement ends the current
- transaction and a new one starts. A <literal role="stmt">COMMIT</literal>
- means that the changes made in the current transaction are made
- permanent and become visible to other sessions. A
- <literal role="stmt" condition="commit">ROLLBACK</literal> statement, on the other hand,
- cancels all modifications made by the current transaction. Both
- <literal role="stmt">COMMIT</literal> and <literal role="stmt" condition="commit">ROLLBACK</literal>
+ transaction open. An SQL <literal role="stmt">COMMIT</literal>
+ or <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement ends the current transaction and a new one starts. A
+ <literal role="stmt">COMMIT</literal> means that the changes
+ made in the current transaction are made permanent and become
+ visible to other sessions. A
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement, on the other hand, cancels all modifications made by
+ the current transaction. Both
+ <literal role="stmt">COMMIT</literal> and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
release all <literal>InnoDB</literal> locks that were set during
the current transaction.
</para>
@@ -4792,9 +4797,11 @@
<para>
If the session has autocommit enabled, a multiple-statement
transaction can be performed by starting it with an explicit
- <literal role="stmt" condition="commit">START TRANSACTION</literal> or
-<literal role="stmt" condition="commit">BEGIN</literal>
- statement and ending it with <literal role="stmt">COMMIT</literal> or
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> or
+ <literal role="stmt" condition="commit">BEGIN</literal>
+ statement and ending it with
+ <literal role="stmt">COMMIT</literal> or
<literal role="stmt" condition="commit">ROLLBACK</literal>.
</para>
@@ -5109,7 +5116,8 @@
<para>
Locking of rows for update using <literal>SELECT FOR
UPDATE</literal> only applies when autocommit is disabled
- (either by beginning transaction with <literal role="stmt" condition="commit">START
+ (either by beginning transaction with
+ <literal role="stmt" condition="commit">START
TRANSACTION</literal> or by setting
<literal>AUTOCOMMIT</literal> to 0. If autocommit is enabled,
the rows matching the specification are not locked.
@@ -5515,8 +5523,9 @@
<para>
For details about which statements implicitly end a transaction,
- as if you had done a <literal role="stmt">COMMIT</literal> before executing
- the statement, see <xref linkend="implicit-commit"/>.
+ as if you had done a <literal role="stmt">COMMIT</literal>
+ before executing the statement, see
+ <xref linkend="implicit-commit"/>.
</para>
</section>
@@ -5561,11 +5570,12 @@
As of MySQL 6.0.5, if a <literal role="stmt">SELECT</literal>
calls a stored function in a transaction, and a statement within
the function fails, that statement rolls back. Furthermore, if
- <literal role="stmt" condition="commit">ROLLBACK</literal> is executed after that, the entire
- transaction rolls back. Before 6.0.5, the failed statement did
- not roll back when it failed (even though it might ultimately
- get rolled back by a <literal role="stmt" condition="commit">ROLLBACK</literal> later that
- rolls back the entire transaction).
+ <literal role="stmt" condition="commit">ROLLBACK</literal> is
+ executed after that, the entire transaction rolls back. Before
+ 6.0.5, the failed statement did not roll back when it failed
+ (even though it might ultimately get rolled back by a
+ <literal role="stmt" condition="commit">ROLLBACK</literal> later
+ that rolls back the entire transaction).
</para>
</section>
@@ -5865,8 +5875,9 @@
that MySQL does not have autocommit mode enabled because that
requires a log flush to disk for every insert. To disable
autocommit during your import operation, surround it with
- <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal> and
- <literal role="stmt">COMMIT</literal> statements:
+ <literal role="stmt" condition="commit">SET
+ AUTOCOMMIT</literal> and <literal role="stmt">COMMIT</literal>
+ statements:
</para>
<programlisting>
@@ -5879,8 +5890,10 @@
If you use the <command>mysqldump</command> option
<option>--opt</option>, you get dump files that are fast to
import into an <literal>InnoDB</literal> table, even without
- wrapping them with the <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal> and
- <literal role="stmt">COMMIT</literal> statements.
+ wrapping them with the
+ <literal role="stmt" condition="commit">SET
+ AUTOCOMMIT</literal> and <literal role="stmt">COMMIT</literal>
+ statements.
</para>
</listitem>
@@ -7110,12 +7123,14 @@
When a transaction rollback occurs due to a deadlock or lock
wait timeout, it cancels the effect of the statements within
the transaction. But if the start-transaction statement was
- <literal role="stmt" condition="commit">START TRANSACTION</literal> or
- <literal role="stmt" condition="commit">BEGIN</literal> statement, rollback does not cancel
- that statement. Further SQL statements become part of the
- transaction until the occurrence of <literal role="stmt">COMMIT</literal>,
- <literal role="stmt" condition="commit">ROLLBACK</literal>, or some SQL statement that causes
- an implicit commit.
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> or
+ <literal role="stmt" condition="commit">BEGIN</literal>
+ statement, rollback does not cancel that statement. Further
+ SQL statements become part of the transaction until the
+ occurrence of <literal role="stmt">COMMIT</literal>,
+ <literal role="stmt" condition="commit">ROLLBACK</literal>, or
+ some SQL statement that causes an implicit commit.
</para>
</listitem>
@@ -7147,10 +7162,11 @@
<para>
During implicit rollbacks, as well as during the execution of an
- explicit <literal role="stmt" condition="commit">ROLLBACK</literal> SQL statement,
- <literal role="stmt">SHOW PROCESSLIST</literal> displays
- <literal>Rolling back</literal> in the <literal>State</literal>
- column for the relevant connection.
+ explicit
+ <literal role="stmt" condition="commit">ROLLBACK</literal> SQL
+ statement, <literal role="stmt">SHOW PROCESSLIST</literal>
+ displays <literal>Rolling back</literal> in the
+ <literal>State</literal> column for the relevant connection.
</para>
<section id="innodb-error-codes">
Modified: trunk/refman-6.0/sql-syntax-data-definition.xml
===================================================================
--- trunk/refman-6.0/sql-syntax-data-definition.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-6.0/sql-syntax-data-definition.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 6, Lines Deleted: 5; 1225 bytes
@@ -3640,11 +3640,12 @@
MySQL allows routines to contain DDL statements, such as
<literal>CREATE</literal> and <literal>DROP</literal>. MySQL also
allows stored procedures (but not stored functions) to contain SQL
- transaction statements such as <literal role="stmt">COMMIT</literal>. Stored
- functions may not contain statements that perform explicit or
- implicit commit or rollback. Support for these statements is not
- required by the SQL standard, which states that each DBMS vendor
- may decide whether to allow them.
+ transaction statements such as
+ <literal role="stmt">COMMIT</literal>. Stored functions may not
+ contain statements that perform explicit or implicit commit or
+ rollback. Support for these statements is not required by the SQL
+ standard, which states that each DBMS vendor may decide whether to
+ allow them.
</para>
<para>
Modified: trunk/refman-6.0/sql-syntax-transactions.xml
===================================================================
--- trunk/refman-6.0/sql-syntax-transactions.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-6.0/sql-syntax-transactions.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 24, Lines Added: 128, Lines Deleted: 91; 21029 bytes
@@ -11,16 +11,20 @@
<para>
MySQL supports local transactions (within a given client session)
- through statements such as <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal>,
- <literal role="stmt" condition="commit">START TRANSACTION</literal>, <literal role="stmt">COMMIT</literal>, and
- <literal role="stmt" condition="commit">ROLLBACK</literal>. See <xref linkend="commit"/>. XA
- transaction support enables MySQL to participate in distributed
- transactions as well. See <xref linkend="xa"/>.
+ through statements such as
+ <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal>,
+ <literal role="stmt" condition="commit">START TRANSACTION</literal>,
+ <literal role="stmt">COMMIT</literal>, and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>. See
+ <xref linkend="commit"/>. XA transaction support enables MySQL to
+ participate in distributed transactions as well. See
+ <xref linkend="xa"/>.
</para>
<section id="commit">
- <title><literal role="stmt" condition="commit">START TRANSACTION</literal>, <literal role="stmt">COMMIT</literal>, and
+ <title><literal role="stmt" condition="commit">START TRANSACTION</literal>,
+ <literal role="stmt">COMMIT</literal>, and
<literal role="stmt" condition="commit">ROLLBACK</literal> Syntax</title>
<indexterm>
@@ -58,18 +62,22 @@
<remark role="help-description-begin"/>
<para>
- The <literal role="stmt" condition="commit">START TRANSACTION</literal> or
- <literal role="stmt" condition="commit">BEGIN</literal> statement begins a new transaction.
- <literal role="stmt">COMMIT</literal> commits the current transaction, making
- its changes permanent. <literal role="stmt" condition="commit">ROLLBACK</literal> rolls back the
- current transaction, canceling its changes. The <literal role="stmt" condition="commit">SET
- AUTOCOMMIT</literal> statement disables or enables the default
- autocommit mode for the current session.
+ The <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> or
+ <literal role="stmt" condition="commit">BEGIN</literal> statement
+ begins a new transaction. <literal role="stmt">COMMIT</literal>
+ commits the current transaction, making its changes permanent.
+ <literal role="stmt" condition="commit">ROLLBACK</literal> rolls
+ back the current transaction, canceling its changes. The
+ <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal>
+ statement disables or enables the default autocommit mode for the
+ current session.
</para>
<para>
The optional <literal>WORK</literal> keyword is supported for
- <literal role="stmt">COMMIT</literal> and <literal role="stmt" condition="commit">ROLLBACK</literal>, as are
+ <literal role="stmt">COMMIT</literal> and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>, as are
the <literal>CHAIN</literal> and <literal>RELEASE</literal>
clauses. <literal>CHAIN</literal> and <literal>RELEASE</literal>
can be used for additional control over transaction completion.
@@ -108,13 +116,15 @@
transaction-safe tables (such as those for
<literal>InnoDB</literal> or <literal>NDBCLUSTER</literal>) are
not made permanent immediately. You must use
- <literal role="stmt">COMMIT</literal> to store your changes to disk or
- <literal role="stmt" condition="commit">ROLLBACK</literal> to ignore the changes.
+ <literal role="stmt">COMMIT</literal> to store your changes to
+ disk or <literal role="stmt" condition="commit">ROLLBACK</literal>
+ to ignore the changes.
</para>
<para>
To disable autocommit mode for a single series of statements, use
- the <literal role="stmt" condition="commit">START TRANSACTION</literal> statement:
+ the <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> statement:
</para>
<note>
@@ -140,18 +150,22 @@
</programlisting>
<para>
- With <literal role="stmt" condition="commit">START TRANSACTION</literal>, autocommit remains
- disabled until you end the transaction with
- <literal role="stmt">COMMIT</literal> or <literal role="stmt" condition="commit">ROLLBACK</literal>. The
+ With <literal role="stmt" condition="commit">START
+ TRANSACTION</literal>, autocommit remains disabled until you end
+ the transaction with <literal role="stmt">COMMIT</literal> or
+ <literal role="stmt" condition="commit">ROLLBACK</literal>. The
autocommit mode then reverts to its previous state.
</para>
<para>
- <literal role="stmt" condition="commit">BEGIN</literal> and <literal role="stmt" condition="commit">BEGIN WORK</literal> are
- supported as aliases of <literal role="stmt" condition="commit">START TRANSACTION</literal> for
- initiating a transaction. <literal role="stmt" condition="commit">START TRANSACTION</literal> is
- standard SQL syntax and is the recommended way to start an ad-hoc
- transaction.
+ <literal role="stmt" condition="commit">BEGIN</literal> and
+ <literal role="stmt" condition="commit">BEGIN WORK</literal> are
+ supported as aliases of
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> for initiating a transaction.
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> is standard SQL syntax and is the
+ recommended way to start an ad-hoc transaction.
</para>
<important>
@@ -159,17 +173,19 @@
Many APIs used for writing MySQL client applications (such as
JDBC) provide their own methods for starting transactions that
can (and sometimes should) be used instead of sending a
- <literal role="stmt" condition="commit">START TRANSACTION</literal> statement from the client.
- See <xref linkend="connectors-apis"/>, or the documentation for
- your API, for more information.
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> statement from the client. See
+ <xref linkend="connectors-apis"/>, or the documentation for your
+ API, for more information.
</para>
</important>
<para>
- The <literal role="stmt" condition="commit">BEGIN</literal> statement differs from the use of the
- <literal>BEGIN</literal> keyword that starts a <literal>BEGIN ...
- END</literal> compound statement. The latter does not begin a
- transaction. See <xref linkend="begin-end"/>.
+ The <literal role="stmt" condition="commit">BEGIN</literal>
+ statement differs from the use of the <literal>BEGIN</literal>
+ keyword that starts a <literal>BEGIN ... END</literal> compound
+ statement. The latter does not begin a transaction. See
+ <xref linkend="begin-end"/>.
</para>
<para>
@@ -190,7 +206,8 @@
<listitem>
<para>
For <literal>InnoDB</literal>, the effect is the same as
- issuing a <literal role="stmt" condition="commit">START TRANSACTION</literal> followed by a
+ issuing a <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> followed by a
<literal role="stmt">SELECT</literal> from any
<literal>InnoDB</literal> table. See
<xref linkend="innodb-consistent-read"/>. The <literal>WITH
@@ -268,8 +285,10 @@
<listitem>
<para>
- If you issue a <literal role="stmt" condition="commit">ROLLBACK</literal> statement after
- updating a non-transactional table within a transaction, an
+ If you issue a
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement after updating a non-transactional table within a
+ transaction, an
<literal>ER_WARNING_NOT_COMPLETE_ROLLBACK</literal> warning
occurs. Changes to transaction-safe tables are rolled back,
but not changes to non-transaction-safe tables.
@@ -280,13 +299,15 @@
<para>
Each transaction is stored in the binary log in one chunk, upon
- <literal role="stmt">COMMIT</literal>. Transactions that are rolled back are
- not logged. (<emphasis role="bold">Exception</emphasis>:
- Modifications to non-transactional tables cannot be rolled back.
- If a transaction that is rolled back includes modifications to
- non-transactional tables, the entire transaction is logged with a
- <literal role="stmt" condition="commit">ROLLBACK</literal> statement at the end to ensure that
- modifications to the non-transactional tables are replicated.) See
+ <literal role="stmt">COMMIT</literal>. Transactions that are
+ rolled back are not logged.
+ (<emphasis role="bold">Exception</emphasis>: Modifications to
+ non-transactional tables cannot be rolled back. If a transaction
+ that is rolled back includes modifications to non-transactional
+ tables, the entire transaction is logged with a
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement at the end to ensure that modifications to the
+ non-transactional tables are replicated.) See
<xref linkend="binary-log"/>.
</para>
@@ -302,7 +323,8 @@
an error occurs). Because of this, <literal role="stmt">SHOW
PROCESSLIST</literal> displays <literal>Rolling back</literal> in
the <literal>State</literal> column for the session, not only for
- explicit rollbacks performed with the <literal role="stmt" condition="commit">ROLLBACK</literal>
+ explicit rollbacks performed with the
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
statement but also for implicit rollbacks.
</para>
@@ -324,7 +346,9 @@
statements. If you issue a statement early in a transaction that
cannot be rolled back, and then another statement later fails, the
full effect of the transaction cannot be rolled back in such cases
- by issuing a <literal role="stmt" condition="commit">ROLLBACK</literal> statement.
+ by issuing a
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement.
</para>
</section>
@@ -336,10 +360,10 @@
<para>
The statements listed in this section (and any synonyms for them)
implicitly end a transaction, as if you had done a
- <literal role="stmt">COMMIT</literal> before executing the statement. As of
- MySQL 6.0.8, most of these statements also cause an implicit
- commit after executing; for additional details, see the end of
- this section.
+ <literal role="stmt">COMMIT</literal> before executing the
+ statement. As of MySQL 6.0.8, most of these statements also cause
+ an implicit commit after executing; for additional details, see
+ the end of this section.
</para>
<itemizedlist>
@@ -390,7 +414,8 @@
<para>
The <literal role="stmt">CREATE TABLE</literal> statement in
<literal>InnoDB</literal> is processed as a single
- transaction. This means that a <literal role="stmt" condition="commit">ROLLBACK</literal>
+ transaction. This means that a
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
from the user does not undo <literal role="stmt">CREATE
TABLE</literal> statements the user made during that
transaction.
@@ -430,10 +455,12 @@
<listitem>
<para>
<emphasis role="bold">Transaction-control and locking
- statements.</emphasis> <literal role="stmt" condition="commit">BEGIN</literal>,
+ statements.</emphasis>
+ <literal role="stmt" condition="commit">BEGIN</literal>,
<literal role="stmt">LOCK TABLES</literal>, <literal>SET
AUTOCOMMIT=1</literal> (if the value is not already 1),
- <literal role="stmt" condition="commit">START TRANSACTION</literal>,
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal>,
<literal role="stmt" condition="lock-tables">UNLOCK
TABLES</literal>.
</para>
@@ -454,8 +481,8 @@
<para>
Transactions cannot be nested. This is a consequence of the
implicit commit performed for any current transaction when you
- issue a <literal role="stmt" condition="commit">START TRANSACTION</literal> statement or one
- of its synonyms.
+ issue a <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> statement or one of its synonyms.
</para>
<para>
@@ -465,11 +492,11 @@
</para>
<para>
- The <literal role="stmt" condition="commit">BEGIN</literal> statement differs from the use of
- the <literal>BEGIN</literal> keyword that starts a
- <literal>BEGIN ... END</literal> compound statement. The
- latter does not cause an implicit commit. See
- <xref linkend="begin-end"/>.
+ The <literal role="stmt" condition="commit">BEGIN</literal>
+ statement differs from the use of the <literal>BEGIN</literal>
+ keyword that starts a <literal>BEGIN ... END</literal>
+ compound statement. The latter does not cause an implicit
+ commit. See <xref linkend="begin-end"/>.
</para>
</listitem>
@@ -539,7 +566,8 @@
<section id="savepoints">
- <title><literal role="stmt">SAVEPOINT</literal> and <literal role="stmt" condition="commit">ROLLBACK TO
+ <title><literal role="stmt">SAVEPOINT</literal> and
+ <literal role="stmt" condition="commit">ROLLBACK TO
SAVEPOINT</literal> Syntax</title>
<indexterm>
@@ -574,40 +602,43 @@
<para>
<literal>InnoDB</literal> and Falcon support the SQL statements
- <literal role="stmt">SAVEPOINT</literal>, <literal role="stmt" condition="commit">ROLLBACK TO
- SAVEPOINT</literal>, <literal role="stmt" condition="commit">RELEASE SAVEPOINT</literal> and the
- optional <literal>WORK</literal> keyword for
+ <literal role="stmt">SAVEPOINT</literal>,
+ <literal role="stmt" condition="commit">ROLLBACK TO
+ SAVEPOINT</literal>,
+ <literal role="stmt" condition="commit">RELEASE
+ SAVEPOINT</literal> and the optional <literal>WORK</literal>
+ keyword for
<literal role="stmt" condition="commit">ROLLBACK</literal>.
</para>
<remark role="help-description-end"/>
<para>
- The <literal role="stmt">SAVEPOINT</literal> statement sets a named
- transaction savepoint with a name of
+ The <literal role="stmt">SAVEPOINT</literal> statement sets a
+ named transaction savepoint with a name of
<replaceable>identifier</replaceable>. If the current transaction
has a savepoint with the same name, the old savepoint is deleted
and a new one is set.
</para>
<para>
- The <literal role="stmt" condition="commit">ROLLBACK TO SAVEPOINT</literal> statement rolls back
- a transaction to the named savepoint without terminating the
- transaction. Modifications that the current transaction made to
- rows after the savepoint was set are undone in the rollback, but
- <literal>InnoDB</literal> does <emphasis>not</emphasis> release
- the row locks that were stored in memory after the savepoint.
- (Note that for a new inserted row, the lock information is carried
- by the transaction ID stored in the row; the lock is not
- separately stored in memory. In this case, the row lock is
- released in the undo.) Savepoints that were set at a later time
- than the named savepoint are deleted.
+ The <literal role="stmt" condition="commit">ROLLBACK TO
+ SAVEPOINT</literal> statement rolls back a transaction to the
+ named savepoint without terminating the transaction. Modifications
+ that the current transaction made to rows after the savepoint was
+ set are undone in the rollback, but <literal>InnoDB</literal> does
+ <emphasis>not</emphasis> release the row locks that were stored in
+ memory after the savepoint. (Note that for a new inserted row, the
+ lock information is carried by the transaction ID stored in the
+ row; the lock is not separately stored in memory. In this case,
+ the row lock is released in the undo.) Savepoints that were set at
+ a later time than the named savepoint are deleted.
</para>
<para>
- If the <literal role="stmt" condition="commit">ROLLBACK TO SAVEPOINT</literal> statement returns
- the following error, it means that no savepoint with the specified
- name exists:
+ If the <literal role="stmt" condition="commit">ROLLBACK TO
+ SAVEPOINT</literal> statement returns the following error, it
+ means that no savepoint with the specified name exists:
</para>
<programlisting>
@@ -615,16 +646,17 @@
</programlisting>
<para>
- The <literal role="stmt" condition="commit">RELEASE SAVEPOINT</literal> statement removes the
- named savepoint from the set of savepoints of the current
- transaction. No commit or rollback occurs. It is an error if the
- savepoint does not exist.
+ The <literal role="stmt" condition="commit">RELEASE
+ SAVEPOINT</literal> statement removes the named savepoint from the
+ set of savepoints of the current transaction. No commit or
+ rollback occurs. It is an error if the savepoint does not exist.
</para>
<para>
All savepoints of the current transaction are deleted if you
execute a <literal role="stmt">COMMIT</literal>, or a
- <literal role="stmt" condition="commit">ROLLBACK</literal> that does not name a savepoint.
+ <literal role="stmt" condition="commit">ROLLBACK</literal> that
+ does not name a savepoint.
</para>
<para>
@@ -1081,7 +1113,8 @@
<para>
Transactional locks do not apply if a session is not in
transactional context; that is, when autocommit mode is enabled
- because the session has not used <literal role="stmt" condition="commit">START
+ because the session has not used
+ <literal role="stmt" condition="commit">START
TRANSACTION</literal> or <literal>SET AUTOCOMMIT = 0</literal>. In
this case, the lock is released as soon as the
<literal role="stmt">LOCK TABLES</literal> statement ends, which
@@ -1269,7 +1302,8 @@
<listitem>
<para>
Ending a transaction explicitly, by either
- <literal role="stmt">COMMIT</literal> or <literal role="stmt" condition="commit">ROLLBACK</literal>,
+ <literal role="stmt">COMMIT</literal> or
+ <literal role="stmt" condition="commit">ROLLBACK</literal>,
releases existing locks.
</para>
</listitem>
@@ -1608,7 +1642,8 @@
<listitem>
<para>
- Beginning a transaction (for example, with <literal role="stmt" condition="commit">START
+ Beginning a transaction (for example, with
+ <literal role="stmt" condition="commit">START
TRANSACTION</literal>) implicitly commits any current
transaction and releases existing locks.
</para>
@@ -1630,8 +1665,9 @@
TABLES</literal> with non-tranactional locks and transactional
tables, such as <literal>InnoDB</literal> tables, is to begin
a transaction with <literal>SET AUTOCOMMIT = 0</literal> (not
- <literal role="stmt" condition="commit">START TRANSACTION</literal>) followed by
- <literal role="stmt">LOCK TABLES</literal>, and to not call
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal>) followed by <literal role="stmt">LOCK
+ TABLES</literal>, and to not call
<literal role="stmt" condition="lock-tables">UNLOCK
TABLES</literal> until you commit the transaction explicitly.
When you call <literal role="stmt">LOCK TABLES</literal>,
@@ -1653,8 +1689,8 @@
<listitem>
<para>
- <literal role="stmt" condition="commit">ROLLBACK</literal> does not release non-transactional
- table locks.
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ does not release non-transactional table locks.
</para>
</listitem>
@@ -2592,7 +2628,8 @@
START</literal> has been issued to begin an XA transaction, a
local transaction cannot be started until the XA transaction has
been committed or rolled back. Conversely, if a local
- transaction has been started with <literal role="stmt" condition="commit">START
+ transaction has been started with
+ <literal role="stmt" condition="commit">START
TRANSACTION</literal>, no XA statements can be used until the
transaction has been committed or rolled back.
</para>
Modified: trunk/refman-6.0/storage-engines.xml
===================================================================
--- trunk/refman-6.0/storage-engines.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-6.0/storage-engines.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 5, Lines Deleted: 4; 1061 bytes
@@ -796,15 +796,16 @@
<listitem>
<para>
You can combine many statements and accept them all at the
- same time with the <literal role="stmt">COMMIT</literal> statement (if
- autocommit is disabled).
+ same time with the <literal role="stmt">COMMIT</literal>
+ statement (if autocommit is disabled).
</para>
</listitem>
<listitem>
<para>
- You can execute <literal role="stmt" condition="commit">ROLLBACK</literal> to ignore your
- changes (if autocommit is disabled).
+ You can execute
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ to ignore your changes (if autocommit is disabled).
</para>
</listitem>
Modified: trunk/refman-6.0/stored-programs-views.xml
===================================================================
--- trunk/refman-6.0/stored-programs-views.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-6.0/stored-programs-views.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 2, Lines Added: 19, Lines Deleted: 14; 3076 bytes
@@ -844,17 +844,20 @@
procedure execution are replicated correctly. That is, the
server logs those statements within the procedure that
actually execute and modify data, and also logs
- <literal role="stmt" condition="commit">BEGIN</literal>, <literal role="stmt">COMMIT</literal>, and
- <literal role="stmt" condition="commit">ROLLBACK</literal> statements as necessary. For
- example, if a procedure updates only transactional tables
- and is executed within a transaction that is rolled back,
- those updates are not logged. If the procedure occurs
- within a committed transaction, <literal role="stmt" condition="commit">BEGIN</literal>
- and <literal role="stmt">COMMIT</literal> statements are logged with
- the updates. For a procedure that executes within a
- rolled-back transaction, its statements are logged using
- the same rules that would apply if the statements were
- executed in standalone fashion:
+ <literal role="stmt" condition="commit">BEGIN</literal>,
+ <literal role="stmt">COMMIT</literal>, and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statements as necessary. For example, if a procedure
+ updates only transactional tables and is executed within a
+ transaction that is rolled back, those updates are not
+ logged. If the procedure occurs within a committed
+ transaction,
+ <literal role="stmt" condition="commit">BEGIN</literal>
+ and <literal role="stmt">COMMIT</literal> statements are
+ logged with the updates. For a procedure that executes
+ within a rolled-back transaction, its statements are
+ logged using the same rules that would apply if the
+ statements were executed in standalone fashion:
</para>
<itemizedlist>
@@ -876,9 +879,11 @@
<para>
Updates to a mix of transactional and
non-transactional tables are logged surrounded by
- <literal role="stmt" condition="commit">BEGIN</literal> and
- <literal role="stmt" condition="commit">ROLLBACK</literal> so that slaves will make
- the same changes and rollbacks as on the master.
+ <literal role="stmt" condition="commit">BEGIN</literal>
+ and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ so that slaves will make the same changes and
+ rollbacks as on the master.
</para>
</listitem>
Modified: trunk/refman-6.0/triggers.xml
===================================================================
--- trunk/refman-6.0/triggers.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-6.0/triggers.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 1, Lines Added: 4, Lines Deleted: 3; 898 bytes
@@ -339,9 +339,10 @@
<listitem>
<para>
The trigger cannot use statements that explicitly or
- implicitly begin or end a transaction such as <literal role="stmt" condition="commit">START
- TRANSACTION</literal>, <literal role="stmt">COMMIT</literal>, or
- <literal role="stmt" condition="commit">ROLLBACK</literal>.
+ implicitly begin or end a transaction such as
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal>, <literal role="stmt">COMMIT</literal>,
+ or <literal role="stmt" condition="commit">ROLLBACK</literal>.
</para>
</listitem>
Modified: trunk/refman-common/news-innodb.xml
===================================================================
--- trunk/refman-common/news-innodb.xml 2008-11-07 19:14:46 UTC (rev 12337)
+++ trunk/refman-common/news-innodb.xml 2008-11-07 19:15:11 UTC (rev 12338)
Changed blocks: 2, Lines Added: 7, Lines Deleted: 5; 1386 bytes
@@ -1321,7 +1321,8 @@
<listitem>
<para>
<literal>InnoDB</literal> now supports the
- <literal role="stmt">SAVEPOINT</literal> and <literal role="stmt" condition="commit">ROLLBACK TO
+ <literal role="stmt">SAVEPOINT</literal> and
+ <literal role="stmt" condition="commit">ROLLBACK TO
SAVEPOINT</literal> SQL statements. See
http://www.innodb.com/ibman.php#Savepoints for the syntax.
</para>
@@ -2722,10 +2723,11 @@
<listitem>
<para>
- <literal>BEGIN</literal> and <literal role="stmt">COMMIT</literal> are now
- added in the binary log around transactions. The MySQL
- replication now respects transaction borders: a user no longer
- sees half transactions in replication slaves.
+ <literal>BEGIN</literal> and
+ <literal role="stmt">COMMIT</literal> are now added in the
+ binary log around transactions. The MySQL replication now
+ respects transaction borders: a user no longer sees half
+ transactions in replication slaves.
</para>
</listitem>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r12338 - in trunk: . dynamic-docs/changelog refman-4.1 refman-5.0 refman-5.1 refman-5.1-maria refman-6.0 refman-common | paul.dubois | 7 Nov |
