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.1 | paul | 21 Jan |
