List:Commits« Previous MessageNext Message »
From:paul Date:January 21 2006 3:09am
Subject:svn commit - mysqldoc@docsrva: r959 - in trunk: . refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: paul
Date: 2006-01-21 04:09:14 +0100 (Sat, 21 Jan 2006)
New Revision: 959

Log:
 r6503@frost:  paul | 2006-01-20 18:24:04 -0600
 Aborted clients can leave a GET_LOCK() lock unavailable. (Bug#10374)


Modified:
   trunk/
   trunk/refman-4.1/functions.xml
   trunk/refman-5.0/functions.xml
   trunk/refman-5.1/functions.xml


Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6500
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2396
   + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6503
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2396

Modified: trunk/refman-4.1/functions.xml
===================================================================
--- trunk/refman-4.1/functions.xml	2006-01-20 23:51:00 UTC (rev 958)
+++ trunk/refman-4.1/functions.xml	2006-01-21 03:09:14 UTC (rev 959)
@@ -13417,11 +13417,21 @@
 </programlisting>
 
           <para>
-            Note that the second <literal>RELEASE_LOCK()</literal> call
-            returns <literal>NULL</literal> because the lock
+            The second <literal>RELEASE_LOCK()</literal> call returns
+            <literal>NULL</literal> because the lock
             <literal>'lock1'</literal> was automatically released by the
             second <literal>GET_LOCK()</literal> call.
           </para>
+
+          <para>
+            Note: If the client that holds the lock for a name
+            terminates abnormally such that it does not close its
+            connection to the MySQL server, the server might not notice
+            for a long time that the connection has become invalid.
+            Until it does notice (at which time it releases the lock),
+            other clients are prevented from acquiring a lock for the
+            same name. This is a known bug.
+          </para>
         </listitem>
 
         <listitem>

Modified: trunk/refman-5.0/functions.xml
===================================================================
--- trunk/refman-5.0/functions.xml	2006-01-20 23:51:00 UTC (rev 958)
+++ trunk/refman-5.0/functions.xml	2006-01-21 03:09:14 UTC (rev 959)
@@ -13445,11 +13445,21 @@
 </programlisting>
 
           <para>
-            Note that the second <literal>RELEASE_LOCK()</literal> call
-            returns <literal>NULL</literal> because the lock
+            The second <literal>RELEASE_LOCK()</literal> call returns
+            <literal>NULL</literal> because the lock
             <literal>'lock1'</literal> was automatically released by the
             second <literal>GET_LOCK()</literal> call.
           </para>
+
+          <para>
+            Note: If the client that holds the lock for a name
+            terminates abnormally such that it does not close its
+            connection to the MySQL server, the server might not notice
+            for a long time that the connection has become invalid.
+            Until it does notice (at which time it releases the lock),
+            other clients are prevented from acquiring a lock for the
+            same name. This is a known bug.
+          </para>
         </listitem>
 
         <listitem>

Modified: trunk/refman-5.1/functions.xml
===================================================================
--- trunk/refman-5.1/functions.xml	2006-01-20 23:51:00 UTC (rev 958)
+++ trunk/refman-5.1/functions.xml	2006-01-21 03:09:14 UTC (rev 959)
@@ -13834,11 +13834,21 @@
 </programlisting>
 
           <para>
-            Note that the second <literal>RELEASE_LOCK()</literal> call
-            returns <literal>NULL</literal> because the lock
+            The second <literal>RELEASE_LOCK()</literal> call returns
+            <literal>NULL</literal> because the lock
             <literal>'lock1'</literal> was automatically released by the
             second <literal>GET_LOCK()</literal> call.
           </para>
+
+          <para>
+            Note: If the client that holds the lock for a name
+            terminates abnormally such that it does not close its
+            connection to the MySQL server, the server might not notice
+            for a long time that the connection has become invalid.
+            Until it does notice (at which time it releases the lock),
+            other clients are prevented from acquiring a lock for the
+            same name. This is a known bug.
+          </para>
         </listitem>
 
         <listitem>

Thread
svn commit - mysqldoc@docsrva: r959 - in trunk: . refman-4.1 refman-5.0 refman-5.1paul21 Jan