bk commit - mysqldoc tree (marko:1.2213)

[Marko Mäkelä]

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

ChangeSet
  1.2213 04/10/15 15:06:42 marko@stripped +1 -0
  manual.texi:
    Document the new flag innodb_table_locks_old_behavior.

  Docs/manual.texi
    1.2100 04/10/15 15:05:59 marko@stripped +34 -10
    Document the new flag innodb_table_locks_old_behavior.

# This is a BitKeeper patch.  What follows are the unified diffs for the
# set of deltas contained in the patch.  The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User:	marko
# Host:	hundin.mysql.fi
# Root:	/home/marko/k/mysqldoc

--- 1.2099/Docs/manual.texi	Fri Oct 15 09:09:40 2004
+++ 1.2100/Docs/manual.texi	Fri Oct 15 15:05:59 2004
@@ -67203,16 +67203,30 @@
 @c @code{INSERT DELAYED} is not supported for @code{InnoDB} tables.
 
 @item
-The MySQL @code{LOCK TABLES} operation does not know about @code{InnoDB}
-row-level locks set by already completed SQL statements. This means that
-you can get a table lock on a table even if there still exist transactions
-by other users who have row level locks on the same table. Thus
-your operations on the table may have to wait if they collide with
-these locks of other users. Also a deadlock is possible. However,
-this does not endanger transaction integrity, because the row level
-locks set by @code{InnoDB} will always take care of the integrity.
-Also, a table lock prevents other transactions from acquiring more
-row level locks (in a conflicting lock mode) on the table.
+Before MySQL 4.0.20 or 4.1.2, the MySQL @code{LOCK TABLES} operation
+does not know about @code{InnoDB} row-level locks set by already
+completed SQL statements. This means that you can get a table lock on
+a table even if there still exist transactions by other users who have
+row level locks on the same table. Thus your operations on the table
+may have to wait if they collide with these locks of other users. Also
+a deadlock is possible. However, this does not endanger transaction
+integrity, because the row level locks set by @code{InnoDB} will
+always take care of the integrity.  Also, a table lock prevents other
+transactions from acquiring more row level locks (in a conflicting
+lock mode) on the table.
+
+@item
+Beginning with MySQL 4.0.20 and 4.1.2, the MySQL @code{LOCK TABLES}
+operation acquires two locks on each table: a table lock on the MySQL
+layer, and an @code{InnoDB} table lock.  The @code{InnoDB} table locks
+will be released when the transaction is committed or aborted.  Thus,
+it does not make much sense to invoke @code{LOCK TABLES} on
+@code{InnoDB} tables in @code{AUTOCOMMIT=1} mode, because the acquired
+@code{InnoDB} table locks would be released immediately.  Starting
+with MySQL 4.0.22 and 4.1.7 there is a startup option and settable
+variable @code{innodb_table_locks_old_behavior}, which makes
+@code{LOCK TABLES} behave in the old way: no @code{InnoDB} lock will
+be taken.
 
 @item
 Before MySQL 3.23.52,
@@ -91166,6 +91180,11 @@
 
 Functionality added or changed:
 @itemize @bullet
+@item
+InnoDB: Added a startup option and settable variable
+@code{innodb_table_locks_old_behavior}, which makes @code{LOCK TABLES}
+behave like it did before 4.0.20 or 4.1.2: no @code{InnoDB} lock will
+be taken.  @xref{InnoDB restrictions}.  (Bug #3299, Bug #5998)
 @end itemize
 
 Bugs fixed:
@@ -92977,6 +92996,11 @@
 
 Functionality added or changed:
 @itemize @bullet
+@item
+InnoDB: Added a startup option and settable variable
+@code{innodb_table_locks_old_behavior}, which makes @code{LOCK TABLES}
+behave like it did before 4.0.20 or 4.1.2: no @code{InnoDB} lock will
+be taken.  @xref{InnoDB restrictions}.  (Bug #3299, Bug #5998)
 @item 
 The @code{--with-openssl} option for @command{configure} now accepts a path
 prefix as an argument. @code{--with-openssl-includes} and