svn commit - mysqldoc@docsrva: r12079 - trunk/dynamic-docs/changelog

[anthony.bedford]

Author: tbedford
Date: 2008-10-16 16:42:52 +0200 (Thu, 16 Oct 2008)
New Revision: 12079

Log:
Added entries for bugs #33861, #38782, #39784, and #40031.

Modified:
   trunk/dynamic-docs/changelog/connector-j.xml


Modified: trunk/dynamic-docs/changelog/connector-j.xml
===================================================================
--- trunk/dynamic-docs/changelog/connector-j.xml	2008-10-16 14:27:34 UTC (rev 12078)
+++ trunk/dynamic-docs/changelog/connector-j.xml	2008-10-16 14:42:52 UTC (rev 12079)
Changed blocks: 1, Lines Added: 120, Lines Deleted: 0; 3439 bytes

@@ -5,6 +5,126 @@
   <logentry entrytype="bug">
 
     <bugs>
+      <fixes bugid="40031"/>
+    </bugs>
+
+    <versions>
+      <version ver="5.1.7"/>
+    </versions>
+
+    <message>
+
+      <para>
+        When using the replication driver with
+        <literal>autoReconnect=true</literal>, Connector/J checks in
+        <literal>PreparedStatement.execute</literal> (also called by
+        <literal>CallableStatement.execute</literal>) to determine if
+        the first character of the statement is an <quote>S</quote>, in
+        an attempt to block all statements that are not read-only-safe,
+        for example non-<literal>SELECT</literal> statements. However,
+        this also blocked <literal>CALL</literal>s to stored procedures,
+        even if the stored procedures were defined as <literal>SQL READ
+        DATA</literal> or <literal>NO SQL</literal>.
+      </para>
+
+    </message>
+
+  </logentry>
+
+  <logentry entrytype="bug">
+
+    <bugs>
+      <fixes bugid="39784"/>
+    </bugs>
+
+    <versions>
+      <version ver="5.1.7"/>
+    </versions>
+
+    <message>
+
+      <para>
+        When the <literal>LoadBalancingConnectionProxy</literal> handles
+        a <literal>SQLException</literal> with SQL state starting with
+        <quote>08</quote>, it calls
+        <literal>invalidateCurrentConnection</literal>, which in turn
+        removes that <literal>Connection</literal> from
+        <literal>liveConnections</literal> and the
+        <literal>connectionsToHostsMap</literal>, but it did not add the
+        host to the new global blacklist, if the global blacklist was
+        enabled.
+      </para>
+
+      <para>
+        There was also the possibility of a
+        <literal>NullPointerException</literal> when trying to update
+        stats, where
+        <literal>connectionsToHostsMap.get(this.currentConn)</literal>
+        was called:
+      </para>
+
+<programlisting>
+int hostIndex = ((Integer)
this.hostsToListIndexMap.get(this.connectionsToHostsMap.get(this.currentConn))).intValue();
+</programlisting>
+
+      <para>
+        This could happen if a client tried to issue a rollback after
+        catching a <literal>SQLException</literal> caused by a
+        connection failure.
+      </para>
+
+    </message>
+
+  </logentry>
+
+  <logentry entrytype="bug">
+
+    <bugs>
+      <fixes bugid="38782"/>
+    </bugs>
+
+    <versions>
+      <version ver="5.1.7"/>
+    </versions>
+
+    <message>
+
+      <para>
+        When using the random load balancing strategy and starting with
+        two servers that were both unavailable, an
+        <literal>IndexOutOfBoundsException</literal> was generated when
+        removing a server from the <literal>whiteList</literal>.
+      </para>
+
+    </message>
+
+  </logentry>
+
+  <logentry entrytype="bug">
+
+    <bugs>
+      <fixes bugid="33861"/>
+    </bugs>
+
+    <versions>
+      <version ver="5.1.7"/>
+    </versions>
+
+    <message>
+
+      <para>
+        The <literal>loadBalance</literal>
+        <literal>bestResponseTime</literal> blacklists did not have a
+        global state.
+      </para>
+
+    </message>
+
+  </logentry>
+
+  <logentry entrytype="bug">
+
+    <bugs>
       <fixes bugid="39962"/>
     </bugs>