svn commit - mysqldoc@docsrva: r2618 - in trunk: ndbapi refman-common

[jon]

Author: jstephens
Date: 2006-07-04 15:39:22 +0200 (Tue, 04 Jul 2006)
New Revision: 2618

Log:
Documenting Cluster/NDBAPI bugfixes:
	Bug #20252, Bug #20442

Modified:
   trunk/ndbapi/ndb-classes.xml
   trunk/refman-common/news-5.0.xml
   trunk/refman-common/news-5.1.xml

Modified: trunk/ndbapi/ndb-classes.xml
===================================================================
--- trunk/ndbapi/ndb-classes.xml	2006-07-04 12:05:58 UTC (rev 2617)
+++ trunk/ndbapi/ndb-classes.xml	2006-07-04 13:39:22 UTC (rev 2618)
@@ -29308,7 +29308,8 @@
     (
       LockMode <replaceable>mode</replaceable> = LM_Read, 
       Uint32   <replaceable>flags</replaceable> = 0, 
-      Uint32   <replaceable>parallel</replaceable> = 0
+      Uint32   <replaceable>parallel</replaceable> = 0,
+      Uint32   <replaceable>batch</replaceable> = 0
     )
 </programlisting>
             </para>
@@ -29320,7 +29321,7 @@
             <title>Parameters</title>
 
             <para>
-              This method takes three parameters, as shown here:
+              This method takes four parameters, as shown here:
 
               <itemizedlist>
 
@@ -29348,6 +29349,25 @@
                     possible number be used.
                   </para>
                 </listitem>
+                
+                <listitem>
+                  <para>
+                    The <replaceable>batch</replaceable> parameter
+                    specifies how many records will be returned to the
+                    client from the server by the next
+                    <literal>NdbScanOperation::nextResult(true)</literal>
+                    method call. Use <literal>0</literal> to specify the
+                    maximum automatically.
+                  </para>
+                  
+                  <note>
+                    <para>
+                      This parameter was ignored prior to MySQL 5.1.12,
+                      and the maximum was used. (Bug #20252)
+                    </para>
+                  </note>
+                  
+                </listitem>
 
               </itemizedlist>
             </para>
@@ -30486,7 +30506,9 @@
     (
       LockMode <replaceable>mode</replaceable> = LM_Read, 
       Uint32   <replaceable>flags</replaceable> = 0, 
-      Uint32   <replaceable>parallel</replaceable> = 0
+      Uint32   <replaceable>parallel</replaceable> = 0,
+			Uint32   <replaceable>batch</replaceable> = 0
+      
     )
 </programlisting>
               </para>
@@ -30534,6 +30556,24 @@
                       automatically.
                     </para>
                   </listitem>
+                  
+                  <listitem>
+                    <para>
+                      The <replaceable>batch</replaceable> parameter
+                      specifies how many records will be returned to the
+                      client from the server by the next
+                      <literal>NdbScanOperation::nextResult(true)</literal>
+                      method call. Use <literal>0</literal> to specify the
+                      maximum automatically.
+                    </para>
+                    
+                    <note>
+                      <para>
+                        This parameter was ignored prior to MySQL
+                        5.1.12, and the maximum was used.(Bug #20252)
+                      </para>
+                    </note>                    
+                  </listitem>
 
                 </itemizedlist>
               </para>

Modified: trunk/refman-common/news-5.0.xml
===================================================================
--- trunk/refman-common/news-5.0.xml	2006-07-04 12:05:58 UTC (rev 2617)
+++ trunk/refman-common/news-5.0.xml	2006-07-04 13:39:22 UTC (rev 2618)
@@ -211,6 +211,31 @@
       
       <listitem>
         <para>
+          <literal>NDB Cluster</literal> (NDB API): When multiple
+          processes or threads in parallel were performing a scan with
+          an exclusive lock, then updated only one record from the
+          subset cached in the client by
+          <literal>nextResults(true)</literal>, calling 
+          <literal>NdbIndexScanOperation::close()</literal>,
+          <literal>NdbTransaction::close()</literal>, or
<literal>Ndb::closeTransaction()</literal>
+          caused a deadlock, finishing only after the
+          <literal>TransactionDeadlockDetectionTimeout</literal> timer
+          expired and the transaction coordinator aborted the
+          transaction. (Bug #20442)
+        </para>
+      </listitem>
+      
+      <listitem>
+        <para>
+          <literal>NDB Cluster</literal> (NDB API):
+          <literal>NdbScanOperation::readTuples()</literal> and
+          <literal>NdbIndexScanOperation::readTuples()</literal> ignored
+          the <replaceable>batch</replaceable> parameter. (Bug #20252)
+        </para>
+      </listitem>
+      
+      <listitem>
+        <para>
           Certain queries having a <literal>WHERE</literal> clause that
           included conditions on multi-part keys with more than 2 key
           parts could produce incorrect results and send

Modified: trunk/refman-common/news-5.1.xml
===================================================================
--- trunk/refman-common/news-5.1.xml	2006-07-04 12:05:58 UTC (rev 2617)
+++ trunk/refman-common/news-5.1.xml	2006-07-04 13:39:22 UTC (rev 2618)
@@ -344,6 +344,31 @@
       
       <listitem>
         <para>
+          <literal>NDB Cluster</literal> (NDB API): When multiple
+          processes or threads in parallel were performing a scan with
+          an exclusive lock, then updated only one record from the
+          subset cached in the client by
+          <literal>nextResults(true)</literal>, calling 
+          <literal>NdbIndexScanOperation::close()</literal>,
+          <literal>NdbTransaction::close()</literal>, or
<literal>Ndb::closeTransaction()</literal>
+          caused a deadlock, finishing only after the
+          <literal>TransactionDeadlockDetectionTimeout</literal> timer
+          expired and the transaction coordinator aborted the
+          transaction. (Bug #20442)
+        </para>
+      </listitem>
+      
+      <listitem>
+        <para>
+          <literal>NDB Cluster</literal> (NDB API):
+          <literal>NdbScanOperation::readTuples()</literal> and
+          <literal>NdbIndexScanOperation::readTuples()</literal> ignored
+          the <replaceable>batch</replaceable> parameter. (Bug #20252)
+        </para>
+      </listitem>
+      
+      <listitem>
+        <para>
           <literal>NDB Cluster</literal>: Cluster system status
           variables were not updated. (Bug #11459)
         </para>