25.3. MySQL Connector/J

MySQL 5.0

25.3. MySQL Connector/J

MySQL proporciona conectividad para aplicaciones clientes desarrolladas en el lenguaje de programación Java via el JDBC driver, que se llama MySQL Connector/J.

MySQL Connector/J es un driver JDBC-3.0 "Tipo 4", lo que significa que es puramente Java, implementa la versión 3.0 de la especificación JDBC, y se comunica directamente con el servidor MySQL usando el protocolo MySQL.

Este documento está pensado para un desarrollador de JDBC principiante. Si tiene experiencia usando JDBC, puede considerar comenzar con la sección "Instalación del Connector/J".

Mientras JDBC es útil por sí mismo, nos gustaría que si no conoce JDBC tras leer las primeras secciones de este manual, evite usar JDBC "desnudo" excepto para los problemas triviales y considere usar uno de los populares marcos persistentes tales como Hibernate, Spring's JDBC templates o Ibatis SQL Maps para hacer la mayoría del trabajo repetitivo y pesado que a veces se requiere con JDBC.

Esta sección no está diseñada para ser un tutorial de JDBC completo. Si necesita más información acerca de usar JDBC puede estar interesado en los siguentes tutoriales en línea que son más profundos que la información presentada aquí:

25.3.1. Conceptos básicos de JDBC

Esta sección proporciona algún conocimiento general de JDBC.

25.3.1.1. Conectar con MySQL usando DriverManager Interface

Cuando usa JDBC fuera de un servidor de aplicación, la clase DriverManager administra el establecimiento de las conexiones.

El DriverManager necesita que le digan qué drivers JDBC debe usar para hacer la conexión. La forma más fácil de hacerlo es usar Class.forName() en la clase que implemente la interfície java.sql.Driver . Con MySQL Connector/J, el nombre de esta clase es com.mysql.jdbc.Driver. Con este método, puede usar un fichero de configuración externo para proporcionar la clase del driver y los parámetros para usar al conectar a la base de datos.

La siguiente sección de código Java muestra cómo puede registrar MySQL Connector/J desde el método main() de su aplicación:

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

// Notice, do not import com.mysql.jdbc.*
// or you will have problems!

public class LoadDriver {
    public static void main(String[] args) {
        try {
            // The newInstance() call is a work around for some
            // broken Java implementations

            Class.forName("com.mysql.jdbc.Driver").newInstance();
        } catch (Exception ex) {
            // handle the error
        }
}

Una vez que el driver se ha registrado con el DriverManager, puede obtener una instancia de Connection que está conectada a una base de datos particular llamando a DriverManager.getConnection():

Ejemplo 25.1. Obtener una conexión de DriverManager

Este ejemplo muestra cómo puede obtener una instancia de Connection del DriverManager. El método getConnection tiene pocas formas diferentes. Debe consultar la documentación de la API que ser proporciona con su JDK para información más específica sobre cómo usarlo.

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

    ... try {
            Connection conn = DriverManager.getConnection("jdbc:mysql://localhost/test?user=monty&password=greatsqldb");

            // Do something with the Connection

           ....
        } catch (SQLException ex) {
            // handle any errors
            System.out.println("SQLException: " + ex.getMessage());
            System.out.println("SQLState: " + ex.getSQLState());
            System.out.println("VendorError: " + ex.getErrorCode());
        }

Una vez que se establece una conexión, puede usarse para crear Statements y PreparedStatements, así como obtener metadatos sobre la base de datos. Esto se explica en las siguientes secciones.

25.3.1.2. Usando Statements para ejecutar SQL

Statements le permiten ejecutar consultas básicas SQL y recibir los resultados mediante la clase ResultSet que se describe posteriormente.

Para crear una instancia de Statement, debe llamar al método createStatement() en el objeto Connection que ha obtenido via uno de los métodos DriverManager.getConnection() o DataSource.getConnection() descritos anteriormente.

Una vez que tiene una instancia de Statement, puede ejecutar una consulta SELECT llamando al método executeQuery(String) con el SQL que desea usar.

Para acutalizar datos en la base de datos, use el método executeUpdate(String SQL). Este método retorna el número de registros afectados por el comando de actualización.

Si no sabe de antemano si el comando SQL será un SELECT o un UPDATE/INSERT, puede usar el método execute(String SQL). Este método retornará cierto si el comando SQL era un SELECT, o falso si era un comando UPDATE/INSERT/DELETE. Si la consulta era un SELECT, puede recibir los resultados llamando al método getResultSet(). Si la consulta era un UPDATE/INSERT/DELETE, puede recibir el número de registros afectados llamando a getUpdateCount() en la instancia de Statement.

Ejemplo 25.2. Usando java.sql.Statement para ejecutar una consulta SELECT

// assume conn is an already created JDBC connection
Statement stmt = null;
ResultSet rs = null;

try {
    stmt = conn.createStatement();
    rs = stmt.executeQuery("SELECT foo FROM bar");

    // or alternatively, if you don't know ahead of time that
    // the query will be a SELECT...

    if (stmt.execute("SELECT foo FROM bar")) {
        rs = stmt.getResultSet();
    }

    // Now do something with the ResultSet ....
} finally {
    // it is a good idea to release
    // resources in a finally{} block
    // in reverse-order of their creation
    // if they are no-longer needed

    if (rs != null) {
        try {
            rs.close();
        } catch (SQLException sqlEx) { // ignore }

        rs = null;
    }

    if (stmt != null) {
        try {
            stmt.close();
        } catch (SQLException sqlEx) { // ignore }

        stmt = null;
    }
}

25.3.1.3. Usando CallableStatements para ejecutar procedimientos almacenados

A partir de MySQL 5.0 cuando se usa con Connector/J 3.1.1 o posterior, la interfície está completamente implementada con la excepción del método .

La sintaxis de los procedimientos almacenados de MySQL se docuemta en la sección "Procedimientos almacenados y funciones" del Manual de Referencia de MySQL.

Connector/J expone la funcionalidad de procedimientos almacenados a través de la interfície de JDBC .

El siguiente ejemplo muestra un procedimiento almacenado que retorna el valor de incrementado en 1, y la cadena de carácteres pasada via como :

Ejemplo 25.3. Ejemplo de procedimiento almacenado

CREATE PROCEDURE demoSp(IN inputParam VARCHAR(255), INOUT inOutParam INT)
BEGIN
    DECLARE z INT;
    SET z = inOutParam + 1;
    SET inOutParam = z;

    SELECT inputParam;

    SELECT CONCAT('zyxw', inputParam);
END

Para usar el procedimiento con Connector/J, siga estos pasos:

  1. Prepare el comando llamable usando .

    Tenga en cuenta que tiene que usar la sintaxis de escape JDBC, y que los paréntesis rodeando los parámetros no son opcionales:

    Ejemplo 25.4. Usando Connection.prepareCall()

    import java.sql.CallableStatement;
    
    ...
    
        //
        // Prepare a call to the stored procedure 'demoSp'
        // with two parameters
        //
        // Notice the use of JDBC-escape syntax ({call ...})
        //
    
        CallableStatement cStmt = conn.prepareCall("{call demoSp(?, ?)}");
    
    
    
        cStmt.setString(1, "abcdefg");

    Nota

    es un método costoso, debido a la petición de metadatos que hace el driver para suportar los parámetros de salida. Por razones de rendimiento, intente minimizar llamadas innecesarias a reusando instancias de en su código.

  2. Registre los parámetros de salida (si existen)

    Para recibir los valores de los parámetros de salida (parámetros especificados como o cuando crea el procedimiento almacenado), JDBC requiere que estén especificados antese de la ejecución del comando usando los varios métodos en la interfície :

    Ejemplo 25.5. Registrando parámetros de salida

    import java.sql.Types;
    
    ...
        //
        // Connector/J supports both named and indexed
        // output parameters. You can register output
        // parameters using either method, as well
        // as retrieve output parameters using either
        // method, regardless of what method was
        // used to register them.
        //
        // The following examples show how to use
        // the various methods of registering
        // output parameters (you should of course
        // use only one registration per parameter).
        //
    
        //
        // Registers the second parameter as output
        //
    
        cStmt.registerOutParameter(2);
    
        //
        // Registers the second parameter as output, and
        // uses the type 'INTEGER' for values returned from
        // getObject()
        //
    
        cStmt.registerOutParameter(2, Types.INTEGER);
    
        //
        // Registers the named parameter 'inOutParam'
        //
    
        cStmt.registerOutParameter("inOutParam");
    
        //
        // Registers the named parameter 'inOutParam', and
        // uses the type 'INTEGER' for values returned from
        // getObject()
        //
    
        cStmt.registerOutParameter("inOutParam", Types.INTEGER);
    
    ...

  3. Especifique los parámetros de entrada (si existen)

    Los parámtros de entrada y de entrada/salida se especifican como en los objetos . Sin embargo, también soporta especificar los parámetros por nombre:

    Ejemplo 25.6. Especificando los parámetros de entrada de CallableStatement

    ...
    
        //
        // Set a parameter by index
        //
    
        cStmt.setString(1, "abcdefg");
    
        //
        // Alternatively, set a parameter using
        // the parameter name
        //
    
        cStmt.setString("inputParameter", "abcdefg");
    
        //
        // Set the 'in/out' parameter using an index
        //
    
        cStmt.setInt(2, 1);
    
        //
        // Alternatively, set the 'in/out' parameter
        // by name
        //
    
        cStmt.setInt("inOutParam", 1);
    
    ...

  4. Ejecute , y reciba cualquier conjunto de resultados o parámetros de salida.

    Mientras soporta llamar a cualquiera de los métodos de ejecución de ( , o ), el método más flexible es , ya que no necesita saber de antemano si el procedimiento almacenado retorna un conjunto de resultados:

    Ejemplo 25.7. Recibiendo resultados y parámetros de salida

    ...
    
        boolean hadResults = cStmt.execute();
    
        //
        // Process all returned result sets
        //
    
        while (hadResults) {
            ResultSet rs = cStmt.getResultSet();
    
            // process result set
            ...
    
            hadResults = cStmt.getMoreResults();
        }
    
        //
        // Retrieve output parameters
        //
        // Connector/J supports both index-based and
        // name-based retrieval
        //
    
        int outputValue = cStmt.getInt(1); // index-based
    
        outputValue = cStmt.getInt("inOutParam"); // name-based
    
    ...

25.3.1.4. Recibiendo valores de columna AUTO_INCREMENT

Antes de la versión 3.0 de la API JDBC , no hay una forma estándar de recibir valores clave de bases de datos que soporten 'auto incremento' o columnas identidad. Con drivers JDBC antiguos para MySQL, siempre puede usar un método específico de MySQL en la interfície Statement, o ejecutar la consulta 'SELECT LAST_INSERT_ID()' tras ejecutar un 'INSERT' a una table que tenga una clave AUTO_INCREMENT. Usando el método específico de MySQL no es portable, y ejecutar el 'SELECT' para obtener el valor de la clave AUTO_INCREMENT require otra consulta a la base de datos, lo que no es lo más eficiente. Las siguientes muestras de código demuestran tres formas distintas de recibir valores AUTO_INCREMENT. Primero, demostramos el uso del nuevo método de JDBC-3.0 'getGeneratedKeys()' que es el método preferido para usar si necesita recibir claves AUTO_INCREMENT y tener acceso a JDBC-3.0. El segundo ejemplo muestra cómo puede recibir el mismo valor usando una consulta estándar 'SELECT LAST_INSERT_ID()'. El ejemplo final muestra como conjuntos de resultados actualizables pueden tener el valor AUTO_INCREMENT usando el método 'insertRow()'.

Ejemplo 25.8. Recibiendo valores de columna AUTO_INCREMENT usando Statement.getGeneratedKeys()

   Statement stmt = null;
   ResultSet rs = null;

   try {

    //
    // Create a Statement instance that we can use for
    // 'normal' result sets assuming you have a
    // Connection 'conn' to a MySQL database already
    // available

    stmt = conn.createStatement(java.sql.ResultSet.TYPE_FORWARD_ONLY,
                                java.sql.ResultSet.CONCUR_UPDATABLE);

    //
    // Issue the DDL queries for the table for this example
    //

    stmt.executeUpdate("DROP TABLE IF EXISTS autoIncTutorial");
    stmt.executeUpdate(
            "CREATE TABLE autoIncTutorial ("
            + "priKey INT NOT NULL AUTO_INCREMENT, "
            + "dataField VARCHAR(64), PRIMARY KEY (priKey))");

    //
    // Insert one row that will generate an AUTO INCREMENT
    // key in the 'priKey' field
    //

    stmt.executeUpdate(
            "INSERT INTO autoIncTutorial (dataField) "
            + "values ('Can I Get the Auto Increment Field?')",
            Statement.RETURN_GENERATED_KEYS);

    //
    // Example of using Statement.getGeneratedKeys()
    // to retrieve the value of an auto-increment
    // value
    //

    int autoIncKeyFromApi = -1;

    rs = stmt.getGeneratedKeys();

    if (rs.next()) {
        autoIncKeyFromApi = rs.getInt(1);
    } else {

        // throw an exception from here
    }

    rs.close();

    rs = null;

    System.out.println("Key returned from getGeneratedKeys():"
        + autoIncKeyFromApi);
} finally {

    if (rs != null) {
        try {
            rs.close();
        } catch (SQLException ex) {
            // ignore
        }
    }

    if (stmt != null) {
        try {
            stmt.close();
        } catch (SQLException ex) {
            // ignore
        }
    }
}

Ejemplo 25.9. Recibiendo valores de columna AUTO_INCREMENT usando 'SELECT LAST_INSERT_ID()'

   Statement stmt = null;
   ResultSet rs = null;

   try {

    //
    // Create a Statement instance that we can use for
    // 'normal' result sets.

    stmt = conn.createStatement();

    //
    // Issue the DDL queries for the table for this example
    //

    stmt.executeUpdate("DROP TABLE IF EXISTS autoIncTutorial");
    stmt.executeUpdate(
            "CREATE TABLE autoIncTutorial ("
            + "priKey INT NOT NULL AUTO_INCREMENT, "
            + "dataField VARCHAR(64), PRIMARY KEY (priKey))");

    //
    // Insert one row that will generate an AUTO INCREMENT
    // key in the 'priKey' field
    //

    stmt.executeUpdate(
            "INSERT INTO autoIncTutorial (dataField) "
            + "values ('Can I Get the Auto Increment Field?')");

    //
    // Use the MySQL LAST_INSERT_ID()
    // function to do the same thing as getGeneratedKeys()
    //

    int autoIncKeyFromFunc = -1;
    rs = stmt.executeQuery("SELECT LAST_INSERT_ID()");

    if (rs.next()) {
        autoIncKeyFromFunc = rs.getInt(1);
    } else {
        // throw an exception from here
    }

    rs.close();

    System.out.println("Key returned from " + "'SELECT LAST_INSERT_ID()': "
        + autoIncKeyFromFunc);

} finally {

    if (rs != null) {
        try {
            rs.close();
        } catch (SQLException ex) {
            // ignore
        }
    }

    if (stmt != null) {
        try {
            stmt.close();
        } catch (SQLException ex) {
            // ignore
        }
    }
}
   

Ejemplo 25.10. Recibiendo valores de columna AUTO_INCREMENT en Updatable ResultSets

   Statement stmt = null;
   ResultSet rs = null;

   try {

    //
    // Create a Statement instance that we can use for
    // 'normal' result sets as well as an 'updatable'
    // one, assuming you have a Connection 'conn' to
    // a MySQL database already available
    //

    stmt = conn.createStatement(java.sql.ResultSet.TYPE_FORWARD_ONLY,
                                java.sql.ResultSet.CONCUR_UPDATABLE);

    //
    // Issue the DDL queries for the table for this example
    //

    stmt.executeUpdate("DROP TABLE IF EXISTS autoIncTutorial");
    stmt.executeUpdate(
            "CREATE TABLE autoIncTutorial ("
            + "priKey INT NOT NULL AUTO_INCREMENT, "
            + "dataField VARCHAR(64), PRIMARY KEY (priKey))");

    //
    // Example of retrieving an AUTO INCREMENT key
    // from an updatable result set
    //

    rs = stmt.executeQuery("SELECT priKey, dataField "
       + "FROM autoIncTutorial");

    rs.moveToInsertRow();

    rs.updateString("dataField", "AUTO INCREMENT here?");
    rs.insertRow();

    //
    // the driver adds rows at the end
    //

    rs.last();

    //
    // We should now be on the row we just inserted
    //

    int autoIncKeyFromRS = rs.getInt("priKey");

    rs.close();

    rs = null;

    System.out.println("Key returned for inserted row: "
        + autoIncKeyFromRS);

} finally {

    if (rs != null) {
        try {
            rs.close();
        } catch (SQLException ex) {
            // ignore
        }
    }

    if (stmt != null) {
        try {
            stmt.close();
        } catch (SQLException ex) {
            // ignore
        }
    }
}


   

Cuando ejecuta el código de ejemplo anterior, debe obtener la siguiente salida: Clave retornada de getGeneratedKeys(): 1 Clave retornada de 'SELECT LAST_INSERT_ID()': 1 Clave retornada de registros insertados: 2 Debe tener en cuenta que, a veces, puede ser lioso usar la consulta 'SELECT LAST_INSERT_ID()' , ya que el valor de la función está limitado a una conexión. Así que, si otra consulta ocurre en la misma conexión, el valor será sobreescrito. Por otra parte, el método 'getGeneratedKeys()' está limitado a una instancia de Statement , así que puede usarse incluso si ocurren otras consultas en la misma conexión, pero no en la misma instancia de Statement .

25.3.2. Instalación del Connector/J

Use las siguientes instrucciones para instalar el Connector/J

25.3.2.1. Versiones de software requeridas

25.3.2.1.1. Versiones de Java soportadas

MySQL Connector/J soporta Java-2 JVMs, incluyendo JDK-1.2.x, JDK-1.3.x, JDK-1.4.x y JDK-1.5.x, y requiere JDK-1.4.x o posterior para compilar (pero no para ejecutarse). MySQL Connector/J no soporta JDK-1.1.x o JDK-1.0.x

Debido a la implementación de java.sql.Savepoint, Connector/J 3.1.0 y posterior no se ejecutarán en JDKs posterior a 1.4 a no ser que el verificador de clases esté desactivado (-Xverify:none), ya que el verificador de clases intentará cargar la definición de la clase para java.sql.Savepoint incluso si no accede a él el driver a no ser que use la funcionalidad savepoint.

La funcionalidad de cacheo proporcionada por Connector/J 3.1.0 o posterior tampoco está disponible para JVMs posterior a 1.4.x, ya que se basa en que fue la primera disponible en JDK-1.4.0.

25.3.2.1.2. Guías de versión de MySQL Server

MySQL Connector/J soporta todas las versiones conocidas de MySQL server. Algunas características (claves foranas, conjuntos de resultados actualizables) requieren versiones más recientes de MySQSL para operar.

Al conectar a MySQL server versión 4.1 o posterior, es mejor usar MySQL Connector/J version 3.1, ya que tiene pleno soporte para funcionalidades en las versiones más nuevas del servidor incluyendo carácteres Unicode, vistas, procedimientos almacenados y comandos preparados en el servidor.

Mientras que Connector/J versión 3.0 conecta con MySQL server, versión 4.1 o posterior, e implementa carácteres Unicode y el nuevo mecanismo de autorización, Connector/J 3.0 no se actualizará para soportar nuevas funcionalidades en versiones actuales y futuras del servidor.

25.3.2.1.3. Instalación del Driver y configuración del CLASSPATH

MySQL Connector/J se distribuye como archivo .zip o .tar.gz que contiene las fuentes, los ficheros de clase y ficheros de clase "binarios" .jar llamados "", y a partir del Connector/J 3.1.8 una versión "debug" del driver en un fichero llamado "".

A partir de Connector/J 3.1.9, no proporcionamos los ficheros .class "sin empaquetar", sólo están disponibles en los ficheros JAR que se proporcionan con el driver.

No debe usar la versión "debug" del driver a no ser que se le diga de hacerlo al reportar un problema o bug a MySQL AB, ya que no está diseñado para ejecutarse en entornos de producción, y tendrá un impacto adverso de rendimiento al usarse. El binario debug depende de la biblioteca Aspect/J, que se encuentra en el fichero que se proporciona con la distribución Connector/J.

Necesitará usar la gui apropiada o utilidad de línea de comandos para descomprimir la distribución (por ejemplo, WinZip para el archivo .zip, y "tar" para el archivo .tar.gz ). Como hay nombres de ficheros potencialmente largos en la distribución, usamos el formato de archivo GNU tar. Necesitará usar GNU tar (o una aplicación que entienda el formato de archivo GNU tar) para desempaquetar la variante de la distribución .tar.gz .

Una vez que ha extraído el archivo de distribución, puede instalar el driver poniendo mysql-connector-java-[version]-bin.jar en su classpath, añadiendo la ruta COMPLETA en su variable de entorno CLASSPATH o especificándolo directamente con la opción de línea de comandos -cp al arrancar la JVM

Si va a usar el driver con JDBC DriverManager, debe usar "com.mysql.jdbc.Driver" como la clase que implementa java.sql.Driver.

Ejemplo 25.11. Inicialización de CLASSPATH en UNIX

El siguiente comando funciona para 'csh' en UNIX:

$ setenv CLASSPATH /path/to/mysql-connector-java-[version]-bin.jar:$CLASSPATH

El comando anterior puede añadirse al fichero de arranque apropiado para el shell de inicio para hacer que MySQL Connector/J esté disponible para todas las aplicaciones Java .

Si quiere usar MySQL Connector/J con un servidor de aplicaciones como Tomcat o JBoss, tenrá que consultar la documentación del vendedor para más información sobre cómo configurar bibliotecas de terceras partes, ya que la mayoría de servidores de aplicaciones ignoran la variable de entorno CLASSPATH. Este documento contiene ejemplos de configuración para algunos servidores de aplicaciones J2EE en la sección "Usando Connector/J con J2EE y otros Java Frameworks", sin embargo la fuente autorizada para información de configuración de pools de conexiones JDBC para su servidor de aplicaciones particular es la documentación para dicho servidor de aplicaciones.

Si está desarrollando servletes y/o JSPs, y su servidor de aplicaciones es J2EE-compliant, puede poner el fichero .jar del driver en el subdirectorio WEB-INF/lib de su aplicación, ya que es la localización estándar para bibliotecas class de terceras clases en aplicaciones web J2EE.

También puede usar las clases MysqlDataSource o MysqlConnectionPoolDataSource en el paquete opcional com.mysql.jdbc.jdbc2.optional , si su servidor de aplicaciones J2EE los soporta o requiere. Las distintas clases MysqlDataSource soportan los siguientes parámetros (a través del método estándar "set"):

  • usuario

  • contraseña

  • nombreDelServidor (consulte las secciones anteriores sobre equipos a prueba de fallos)

  • nombreBaseDeDatos

  • puerto

25.3.2.2. Actualizando desde una versión antigua

MySQL AB intenta mantener el proceso de actualización tan fácil como sea posible, sin embargo como pasa con cualquier software, a veces los cambios necesitan hacerse en versiones nuevas para soportar nuevas funcionalidades, mejorar funcionalidades existentes, o cumplir nuevos estándars.

Esta sección tiene información sobre qué tener en cuenta para actualizar de versiones antinguas de Connector/J a otras (o a una nueva versión de MySQL server, con respecto a funcionalidad de JDBC ).

25.3.2.2.1. Actualizando de MySQL Connector/J 3.0 a 3.1

Connector/J 3.1 está diseñado para tener compatibilidad con versiones anteriores a Connector/J 3.0 tanto como sea posible. Los cambios mayores se aislan a nuevas funcionalidades mostradas en MySQL-4.1 y posteriores, que incluyen conjunto de carácteres Unicode, comandos preparados en el servidor, códigos SQLState retornados en mensajes de error por el servidor y varias mejoras de rendimiento que pueden estar activas o desactivadas via propiedades de configuración.

  • Códigos de carácteres Unicode - Consulte la siguientes seción, así como la sección "Conjuntos de carácteres" en el manual del servidor para información de esta nueva funcionalidad de MySQL. Si tiene algo mal configurado, normalmente mostrará un error con un mensaje similar a "Mezcla ilegal de colaciones".

  • Comandos preparados en el servidor - Connector/J 3.1 automáticamente detecta y usa comandos preparados en el servidor cuando están disponibles (versión de MySQL 4.1 y posterior).

    A partir de la versión 3.1.7, el driver escanea el SQL que está preparando via todas las variantes de para determinar si es un tipo de comandos soportado para preparar en el servidor, y si no es soportado por el servidor, lo prepara como un comando preparado emulado en el cliente. Puede desactivar esta característica pasando 'emulateUnsupportedPstmts=false' en JDBC URL.

    Si su aplicación encuentra problemas con comandos preparados en el servidor, puede volver al código de comando preparado en el cliente que se usaba en MySQL server anterior a 4.1.0 con la siguiente propiedad de conexión:

  • Fechas con todos los componentes a cero ('0000-00-00 ...') - Estos valores no pueden representarse correctamente en Java. Connector/J 3.0.x siempre los convierte a NULL cuando empieza a leer de un ResultSet.

    Connector/J 3.1 lanza una excepción por defecto cuando estos valores se encuentran ya que es el comportamiento más correcto según los estándars JDBC y SQL . Este comportamiento puede modificarse usando la propiedad de configuración ' zeroDateTimeBehavior '. Los valores disponibles son: 'exception' (por defecto), que lanza una excepción SQLException con SQLState de 'S1009', 'convertToNull', que retorna NULL en lugar de la fecha, y 'round', que redondea la fecha al valor más cercano que es '0001-01-01'.

    Desde Connector/J 3.1.7, ResultSet.getString() puede desligarse de este comportamiento via ' noDatetimeStringSync=true ' (el valor por defecto es 'false') de forma que pueda recibir el valor de ceros inalterado como cadena de carácteres. Debe tenerse en cuenta que esto deshabilita usar cualquier conversión de zona horaria, por lo tanto el driver no permitirá activar noDatetimeStringSync y useTimezone al mismo tiempo.

  • Nuevos códigos de SQLState - Connector/J 3.1 usa los códigos SQLState SQL:1999 retornados por MySQL server (si está soportado), que son distintos de los códigos de estado "heredados" X/Open que usa Connector/J 3.0. Si está conectado a un servidor MySQL anterior a MySQL-4.1.0 (la versión más vieja que retorna SQLStates como parte del código de error), el driver usará un mapeo por defecto. Puede usar el viejo mapeo usando las siguientes propiedades de configuración:

  • LLamar ResultSet.getString() en una columna BLOB retornará la dirección del array byte[] que lo representa en lugar de una representación de cadenas de carateres del BLOB. BLOBs no tienen conjunto de carácteres, así que no pueden convertirse a java.lang.Strings sin pérdida de datos o corrupción.

    Para almacenar cadenas de carácteres en MySQL con comportamiento LOB , use uno de los tipos TEXT , donde el driver lo tratará como java.sql.Clob.

  • A partir de Connector/J 3.1.8 una versión "debug" del driver llamada "" se proporciona además del fichero "binario" jar que se llama "".

    A partir de Connector/J 3.1.9, no proporcionamos los ficheros .class "sin empaquetar", sólo están disponibles en los ficheros JAR que se proporcionan con el driver.

    No debe usar la versión "debug" del driver a no ser que se le diga que lo haga al reportar un problema o bug a MySQL AB, ya que no está diseñado para ejecutarse en entornos de producción, y tendrá un impacto negativo en el rendimiento al usarse. El binario de debug depende de la biblioteca Aspect/J, localizada en el fichero que viene en la distribución Connector/J.

25.3.2.2.2. Temas específicos de JDBC al actualizar a MySQL Server Version 4.1 o posterior
  • Usando la codificación de carácteres UTF-8 - Antes de MySQL server versión 4.1, la codificación de carácteres UTF-8 no era soportada por el servidor, sin embargo, el driver JDBC podía usarla, permitiendo almacenamiento de varios conjuntos de carácteres en tablas latin1 del servidor.

    A partir de MySQL-4.1, esta funcionalidad está obsoleta. Si tiene aplicaciones que se basan en esta funcionalidad, y no puede actualizarlas a que usen el soporte oficial de carácteres Unicode en MySQL versión 4.1 o posterior, debe añadir la siguiente propiedad a su URL de la conexión:

  • Comandos preparados en el servidor - Connector/J 3.1 detecta automáticamente y usa comandos preparados en el servidor cuando está disponible (MySQL versión 4.1.0 y posterior). Si su aplicación tiene problemas con los comandos preparados en el servidor, puede volver a los comandos preparados emulados en el cliente que se usa en servidores MySQL anteriores a 4.1.0 con la siguiente propiedad de conexión:

25.3.3. Referencia JDBC

25.3.3.1. Nombres de clases Driver/Datasource , Sintaxis URL y propiedades de configuración para el Connector/J

El nombre de la clase que implementa el java.sql.Driver en MySQL Connector/J es 'com.mysql.jdbc.Driver'. El nombre de clase 'org.gjt.mm.mysql.Driver' también es usable para compatibilidad con MM.MySQL. Debe usar este nombre de clase al registrar el driver, o al configurar el software para usar MySQL Connector/J.

El formato JDBC URL para MySQL Connector/J es como sigue, con los elementos opcionales entre corchetes ([, ]) :

jdbc:mysql://[host][,failoverhost...][:port]/[database][?propertyName1][=propertyValue1][&propertyName2][=propertyValue2]...

Si el nombre de equipo no se especifica, por defecto es '127.0.0.1'. Si no se especifica el puerto, por defecto es '3306', el puerto por defecto para servidores MySQL.

jdbc:mysql://[host:port],[host:port].../[database][?propertyName1][=propertyValue1][&propertyName2][=propertyValue2]...

Si no se especifica la base de datos, la conexión se hará sin base de datos específica. En este caso, necesitará llamar al método 'setCatalog()' en la instancia de Connection o especificar completamente el nombre de las tablas con el nombre de la base de datos (p.e. 'SELECT dbname.tablename.colname FROM dbname.tablename...') en su SQL. El no especificar la base de datos en la conexión es sólo útil al construir herramientas con varias bases de datos, como administradores GUI de bases de datos.

MySQL Connector/J tiene controlo de errores. Esto permite al driver soportar el fallo de cualquier número de equipos "esclavos" y todavía hacer consultas de sólo lectura. El control de errores sólo ocurre cuando la conexión está en estado autoCommit(true), ya que el control de errores no puede realizarse cuando hay una transacción en progreso. La mayoría de servidores de aplicación y pools de conexiones tienen autoCommit activado al final de cada transacción/conexión.

La funcionalidad de control de errores tiene el siguiente comportamiento:

Si la propiedad URL "autoReconnect" es falsa: EL control de errores sólo ocurre en la inicialización de la conexión, y el fallo ocurre cuando el driver determina que el primer equipo vuelve a estar disponible.

Si la propiedad URL "autoReconnect" es cierta: El control de errores ocurre cuando el driver determina que la conexión ha fallado (antes de cada consulta), y vuelve al primer equipo cuando determina que el equipo está disponible de nuevo ( después que las consultas queriesBeforeRetryMaster se han realizado).

En cualquier caso, cada vez que esté conectado a un servidor con control de errores, la conexión pasa al estado de sólo lectura, de forma que las consultas nunca se procesarán en el MySQL server).

Las propiedades de configuración definen cómo el Connector/J hace una conexión con el MySQL server. A no ser que se especifique lo contrario, las propiedades pueden asignarse para objetos DataSource o para objetos Connection .

Las propiedades de configuración pueden asignarse de una de las siguientes maneras:

  • Usando los métodos set*() en implementaciones MySQL de java.sql.DataSource (que es el método preferido cuando se usan implementaciones de java.sql.DataSource):

    • com.mysql.jdbc.jdbc2.optional.MysqlDataSource

    • com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource

  • Como par clave/valor en la instancia java.util.Properties pasada a DriverManager.getConnection() o Driver.connect()

  • Como parámetro JDBC URL en la URL dada a java.sql.DriverManager.getConnection(), java.sql.Driver.connect() o la implementación MySQL del método javax.sql.DataSource's setURL() .

    Nota

    Si el mecanismo que usa para configurar una JDBC URL es XML-based, necesitará usar el carácter XML literal & para separar los parámetros de configuración ya que el "ampersand" (&) es un carácter reservado para XML.

Las propiedades se listan en la siguiente tabla:

Tabla 25.1. Propiedades de conexión

Nombre de propiedad Definición Requerido? Valor por defecto Desde la versión
Conexión/Autenticación
user El usuario para conectar como No   all
password La contraseña usada al conectar No   all
socketFactory Nombre de la clase que debe usar el driver para crear las conexiones socket con el servidor. Esta clase debe implementar la interfaz 'com.mysql.jdbc.SocketFactory' y tener un constructor público sin argumentos. No com.mysql.jdbc.StandardSocketFactory 3.0.3
connectTimeout Tiempo máximo para conectar al socket (en milisegundos), 0 significa que no hay límite. Sólo funciona en JDK-1.4 o posterior. Por defecto es '0'. No 0 3.0.1
socketTimeout Tiempo máximo en operaciones de red del socket (0, por defecto significa que no hay tiempo máximo). No 0 3.0.1
useConfigs Carga la lista de propiedades de configuración separados por comas antes de parsear la URL o aplicar propiedades específicas de usuario. Estas configuraciones se explican en 'Configuraciones' de la documentación. No   3.1.5
interactiveClient Activa el flag CLIENT_INTERACTIVE , que le dice a MySQL que aborte conexiones basadas en INTERACTIVE_TIMEOUT en lugar de WAIT_TIMEOUT No false 3.1.0
propertiesTransform Una implementación de com.mysql.jdbc.ConnectionPropertiesTransform que el driver usará para modificar propiedades URL pasadas al driver antes de intentar una conexión No   3.1.4
useCompression Usa compresión zlib al comunicar con el servidor (true/false)? Por defecto es 'false'. No false 3.0.17
Alta disponibilidad y Clustering
autoReconnect Debe el driver intentar reestablecer conexiones atascadas y/o muertas? Si está activo el driver lanza una excepción para consultas lanzadas en conexiones atascadas o muertas, que pertenecen a la transacción actual, pero tratarán de reconectar antes de la siguiente consulta ejecutada en la conexión en una nueva transacción. El uso de esta característica no está recomendado, ya que tiene efectos relacionados con el estado de la sesión y la consistencia de datos cuando las aplicaicones no tratan las SQLExceptions apropiadamente, y sólo está diseñado para usarse cuando no es capaz de configurar su aplicación para tratar SQLExceptions resultantes de conexiones atascadas y/o muertas. Alternativamente, investigue las propiedades de la variable de MySQL "wait_timeout" para valores altos en lugar del valor por defecto de 8 horas. No false 1.1
autoReconnectForPools Usa una estrategia de reconexión apropiada para pools de conexiones (por defecto a 'false') No false 3.1.3
failOverReadOnly Cuando falla en modo autoReconnect , debe ponerse la conexión en modo 'sólo lectura'? No true 3.0.12
reconnectAtTxEnd Si autoReconnect es cierto, debe el driver intentar reconexiones tras cada transacción? No false 3.0.10
roundRobinLoadBalance Cuando autoReconnect está activo y failoverReadonly es falso, debemos elegir equipos para conectar en modo round-robin ? No false 3.1.2
queriesBeforeRetryMaster Número de consultas a lanzar antes de volver al maestro cuando falla (cuando se usa control de errores de multi equipos). La condición que se encuentr primero , 'queriesBeforeRetryMaster' o 'secondsBeforeRetryMaster' causará un intento de reconexión al maestro. Por defecto es 50. No 50 3.0.2
secondsBeforeRetryMaster Cuánto debe esperar el driver, cuando falla, antes de intentar reconectar al servidor maestro? La condición que se encuentre primero, 'queriesBeforeRetryMaster' o 'secondsBeforeRetryMaster' causará un intento de reconexión al maestro. El tiempo es en segundos, y por defecto es 30 No 30 3.0.2
enableDeprecatedAutoreconnect La funcionalidad de auto-reconectar está obsoleta desde la versión 3.2 y se eliminará en la versión 3.3. Poner esta propiedad a 'true' para desactivar el chequeo para configurar la característica. No false 3.2.1
Security
allowMultiQueries Permite el uso de ';' para delimitar múltiples consultas durante un comando (true/false, por defecto es 'false' No false 3.1.1
useSSL Usa SSL al comunicar con el servidor (true/false), por defecto es 'false' No false 3.0.2
requireSSL Requiere conexión SSL si useSSL=true? (por defecto es 'false'). No false 3.1.0
allowUrlInLocalInfile Debe permitir el driver URLs en comandos 'LOAD DATA LOCAL INFILE'? No false 3.1.4
paranoid Toma medidas para prevenir la exposición de información sensible en mensajes de error y estructuras de datos transparentes con datos sensibles cuando sea posible? (por defecto es 'false') No false 3.0.1
Extensiones de rendimiento
metadataCacheSize Número de consultas para cacheResultSetMetadata por si cacheResultSetMetaData es 'true' (por defecto es 50) No 50 3.1.1
prepStmtCacheSize Si el cacheo de comandos preparados está activado, cuántos comandos preparados deben cachearse? No 25 3.0.10
prepStmtCacheSqlLimit Si el cacheo de comandos preparados está activado, cuál es el mayor SQL que el driver cacheará? No 256 3.0.10
maintainTimeStats Debe el driver mantener varios temporizadores internos para permitir cálculos en tiempo inactivo además de mensajes de error más explícitos cuando fallan las conexiones al servidor? Poner esta propiedad a falso elimina al menos dos llamadas a System.getCurrentTimeMillis() por consulta. No true 3.1.9
blobSendChunkSize Tamaño de trozo a usar cuando se envía BLOB/CLOBs via ServerPreparedStatements No 1048576 3.1.9
cacheCallableStmts Debe el driver cachear la etapa de parseo de CallableStatements No false 3.1.2
cachePrepStmts Debe el driver cachear la etapa de parseo de PreparedStatements de comandos preparados en el cliente, el "chequeo" para ver si están disponibles los comandos preparados en el cliente y en el servidor? No false 3.0.10
cacheResultSetMetadata Debe el driver cachear ResultSetMetaData para Statements y PreparedStatements? (Req. JDK-1.4+, true/false, por defecto 'false') No false 3.1.1
cacheServerConfiguration Debe el driver cachear los resultados de 'SHOW VARIABLES' y 'SHOW COLLATION' para cada URL? No false 3.1.5
dontTrackOpenResources La especificación JDBC requiere que el driver tracee y cierre automáticamente los recursos, sin embargo si su aplicación no hace un buen trabajo de llamar específicamene a close() en comandos o conjuntos de resultados, puede causar falta de memoria. Poner esta propiedad a true relaja esta restricción, y puede ser más eficiente en cuanto a memoria para algunas aplicaciones. No false 3.1.7
dynamicCalendars Debe el driver recibir el calendario por defecto cuando se requiera, o cachearlo para cada conexión/sesión? No false 3.1.5
elideSetAutoCommits Si usa MySQL-4.1 o posterior, debe el driver ejecutar sólo consultas 'set autocommit=n' cuando el estado del servidor no coincida con el estado pedido por Connection.setAutoCommit(boolean)? No false 3.1.3
holdResultsOpenOverStatementClose Debe el driver cerrar los conjuntos de resultados en Statement.close() como se requiere en la especificación de JDBC? No false 3.1.7
locatorFetchBufferSize Si 'emulateLocators' se configura a 'true', qué tamaño de búffer debe usarse al tratar datos BLOB para getBinaryInputStream? No 1048576 3.2.1
useFastIntParsing Usar rutinas de conversión interna String->Integer para evitar creación excesiva de objetos? No true 3.1.4
useLocalSessionState Debe el driver referirse a valores internos de autocommit e isolación de transacciones que se asignan por Connection.setAutoCommit() y Connection.setTransactionIsolation(), en lugar de consultar la base de datos? No false 3.1.7
useNewIO Debe usar el driver las interfícies java.nio.* para comunicación de red (true/false), por defecto es 'false' No false 3.1.0
useReadAheadInput Usa el último, optimizado y no bloqueante, torrente de entrada usando búffer al leer del servidor? No true 3.1.5
Depurar/Creación de perfiles
logger El nombre de una clase que implementa 'com.mysql.jdbc.log.Log' que se usa para loguer mensajes .(por defecto es 'com.mysql.jdbc.log.StandardLogger', que loguea en STDERR) No com.mysql.jdbc.log.StandardLogger 3.1.1
profileSQL Tracea consultas y su tiempo de ejecución/lectura de datos al log configurado (true/false) por defecto es 'false' No false 3.1.0
reportMetricsIntervalMillis Si 'gatherPerfMetrics' está activo, con qué frecuencia deben loguearse (en ms)? No 30000 3.1.2
maxQuerySizeToLog Controla el máximo tamaño/longitud de una consulta que se logueará al crear un perfil o traceo No 2048 3.1.3
packetDebugBufferSize Número máximo de paquetes a mantener cuando 'enablePacketDebug' es true No 20 3.1.3
slowQueryThresholdMillis Si 'logSlowQueries' está activo, cuánto puede durar la consulta (en ms) antes de ser logueada como 'lenta'? No 2000 3.1.2
useUsageAdvisor Debe el driver mostrar advertencias 'de uso' advirtiendo uso apropiado y eficiente de JDBC y MySQL Connector/J en el log (true/false, por defecto es 'false')? No false 3.1.1
autoGenerateTestcaseScript Debe el driver volcar el SQL que está ejecutando, incluyendo comandos preparados en el servidor en STDERR? No false 3.1.9
dumpQueriesOnException Debe el driver volcar los contenidos de la consulta enviada al servidor en el mensaje para SQLExceptions? No false 3.1.3
enablePacketDebug Cuando está activo, se guarda un búffer circular de paquetes con tamaño 'packetDebugBufferSize' , y volcados cuando se lanzan excepciones en áreas claves del código del driver No false 3.1.3
explainSlowQueries Si 'logSlowQueries' está activo, debe el driver ejecutar un 'EXPLAIN' automáticamente al servidor y enviar los resultados al log condigurado en nivel WARN? No false 3.1.2
logSlowQueries Deben las consultas que tarden más de 'slowQueryThresholdMillis' loguearse? No false 3.1.2
traceProtocol Debe el protocolo de red a nivel de trazas loguearse? No false 3.1.2
Varios
useUnicode Debe el driver usar codificación de carácteres Unicode en el tratamiento de cadenas de carácteres? Debe usarse sólo cuando el driver no puede determinar el mapeo del conjunto de carácteres, o trata de forzar al driver de usar un conjunto de carácteres que MySQL no soporta nativamente (como UTF-8), true/false, por defecto es 'true' No false 1.1g
characterEncoding Si 'useUnicode' es cierto, qué codificación de carácteres debe usar el driver cuando trata cadenas de carácteres? (por defecto es 'autodetect') No   1.1g
characterSetResults Conjunto de carácteres para decir al servidor cómo retornar los resultados. No   3.0.13
connectionCollation Si está activo, le dice al servido usar la colación via 'set collation_connection' No   3.0.13
sessionVariables Lista separada por comas de pares nombre/valor a enviar como SET SESSION ... al servidor cuando conecta el driver. No   3.1.8
allowNanAndInf Debe el driver permitir valores NaN o +/- INF en PreparedStatement.setDouble()? No false 3.1.5
autoDeserialize Debe el driver detectar automáticamente y de-serializar objetos almacenados en campos BLOB ? No false 3.1.5
capitalizeTypeNames Poner en mayúsculas los nombres de tipos en DatabaseMetaData? (normalmente útil cuando se usan WebObjects, true/false, por defecto es 'false') No false 2.0.7
clobberStreamingResults Esto provoca que un ResultSet 'streaming' se cierre automáticamente, y cualquier dato fuera de lo normal que todavía haga streaming desde el servidor será descartada si otra consulta se ejecuta antes que todos los datos se hayan leído desde el servidor. No false 3.0.9
continueBatchOnError Debe el driver continuar procesando comandos batch si falla un comando. La especificación JDBC permite hacerlo (por defeco 'true'). No true 3.0.3
createDatabaseIfNotExist Crea la base de datos dada en la URL si no existe. Asume que el usuario configurado tiene permisos de creación. No false 3.1.9
emptyStringsConvertToZero Debe el driver permitir conversiones de campos de cadenas de carácteres vacías a '0'? No true 3.1.8
emulateLocators N/A No false 3.1.0
emulateUnsupportedPstmts Debe el driver detectar comandos preparados que no son soportados por el servidor, y replazarlos con la versión emulada en el cliente? No true 3.1.7
ignoreNonTxTables Ignorar advertencias de tablas no-transaccionales para hacer rollback? (por defecto es 'false'). No false 3.0.9
jdbcCompliantTruncation Debe el driver lanzar excepciones java.sql.DataTruncation cuando se truncan los datos como requiere la especificación JDBC cuando se conecta a un servidor que soporte advertencias (MySQL 4.1.0 y posterior)? No true 3.1.2
maxRows Número máximo de registros a retornar (0, por defecto significa retornar todos los registros). No -1 all versions
noDatetimeStringSync No asegura que ResultSet.getDatetimeType().toString().equals(ResultSet.getString()) No false 3.1.7
nullCatalogMeansCurrent Cuando DatabaseMetadataMethods pide un parámetro 'catálogo', significa el valor nulo que use el catálogo actual? (esto no es un estándar de JDBC, pero sigue el comportamiento heredado de versiones anteriores del driver) No true 3.1.8
nullNamePatternMatchesAll Debe el método DatabaseMetaData que acepta parámetros *pattern tratar nulo lo mismo que '%' (esto no es un estándar JDBC, sin embargo versiones anteriores del driver aceptaban esta excepción de la especificación) No true 3.1.8
pedantic Sigue la especificación JDBC rigurosamente. No false 3.0.0
relaxAutoCommit Si la versión a la que conecta el driver MySQL no soporta transacciones, permite llamadas a commit(), rollback() y setAutoCommit() (true/false, por defecto es 'false')? No false 2.0.13
retainStatementAfterResultSetClose Debe reterner el driver la referencia Statement en un ResultSet tras la llamada a ResultSet.close(). Esto no sigue el estándar JDBC-compliant desde JDBC-4.0. No false 3.1.11
rollbackOnPooledClose Debe realizar un rollback() el driver cuando las conexiones lógicas en un pool se cierran? No true 3.0.15
runningCTS13 Permite soluciones para bubs en Sun JDBC compliance testsuite version 1.3 No false 3.1.7
serverTimezone No realiza detección/mapeo de zona horaria. Usada cuando la zona horaria del servidor no mapea a la zona horara de Java No   3.0.2
strictFloatingPoint Usado sólo en versiones antiguas del test de cumplimiento No false 3.0.0
strictUpdates Debe el driver hacer chequeo estricto (todas las claves primarias seleccionadas) de conjuntos de resultados actualizables (true, false, por defecto es 'true')? No true 3.0.4
tinyInt1isBit Debe el driver tratar el tipo de datos TINYINT(1) como BIT ( ya que el driver convierte silenciosamente BIT -> TINYINT(1) cuando crea tablas)? No true 3.0.16
transformedBitIsBoolean Si el driver convierte TINYINT(1) a un tipo distinto, debe usar BOOLEAN en lugar de BIT para compatibilidad futura con MySQL-5.0, ya que MySQL-5.0 tiene tipo BIT ? No false 3.1.9
ultraDevHack Crea PreparedStatements para prepareCall() cuando se requiere, ya que UltraDev está roto y realiza un prepareCall() para _todos_ los comandos? (true/false, por defecto es 'false') No false 2.0.3
useHostsInPrivileges Añade '@hostname' a usuarios en DatabaseMetaData.getColumn/TablePrivileges() (true/false), por defecto es 'true'. No true 3.0.2
useOldUTF8Behavior Usa el comportamiento UTF-8 el driver al comunicar con servidores 4.0 y anteriores No false 3.1.6
useOnlyServerErrorMessages No antepone mensaes de error 'estándar' SQLState a mensajes de error retornados por el servidor. No true 3.0.15
useServerPrepStmts Usa comandos preparados en el servidor si el servidor los soporta? (por defecto es 'true'). No true 3.1.0
useSqlStateCodes Usa códigos de error SQL Standard en lugar de códigos de estado X/Open/SQL 'heredados' (true/false), por defecto es 'true' No true 3.1.3
useStreamLengthsInPrepStmts Honara la longitud de parámetros de flujo en llamadas al método PreparedStatement/ResultSet.setXXXStream() (true/false, por defecto es 'true')? No true 3.0.2
useTimezone Convierte tipos fecha/hora entre zonas horarias del cliente y el servidor (true/false, por defecto es 'false')? No false 3.0.2
useUnbufferedInput No usa BufferedInputStream para leer datos del servidor No true 3.0.11
yearIsDateType Debe el driver JDBC tratar el tipo MySQL "YEAR" como java.sql.Date, o como SHORT? No true 3.1.9
zeroDateTimeBehavior Qué debe ocurrir cuando el driver encuentra valores DATETIME que están compuestos enteramente de ceros (usado por MySQL para representar fechas inválidas)? Valores válidos son 'exception', 'round' y 'convertToNull'. No exception 3.1.4

Connector/J también soporta acceso a MySQL via named pipes en Windows NT/2000/XP usando 'NamedPipeSocketFactory' como plugin-socket factory via la propiedad 'socketFactory'. Si no usa una 'namedPipePath' apropiadamente, se usa por defecto '\\.\pipe\MySQL'. Si usa NamedPipeSocketFactory, el nombre de equipo y puerto en la url JDB se ignoran.

Añadiendo la siguiente propiedad a la URL activa la NamedPipeSocketFactory:

socketFactory=com.mysql.jdbc.NamedPipeSocketFactory

Named pipes sólo funcionan al conectar a un MySQL server en la misma máquina en la que se usa el driver JDBC. En tests de rendimiento simples, parece que el acceso por named pipe es entre un 30%-50% más rápido que acceso TCP/IP estándar.

Puede crear sus propias factorías socket siguiendo el siguiente código de ejemplo en , o .

25.3.3.2. Notas de la implementación del API de JDBC

MySQL Connector/J pasa todos los tests en la versión pública disponible del suite de test de cumplimiento JDBC de Sun. Sin embargo, en muchas partes la especificación JDBC es vaga sobre cómo deben implementarse ciertas funcionalidades, o la especificación permite libertad en la implementación.

Esta sección da detalles a un nivel interfaz-por-interfaz acerca cómo ciertas decisiones de implementación pueden afectar cómo usar el MySQL Connector/J.

  • Blob

    La implementación Blob no permite modificación in-situ (hay 'copias', como se reporta en el método DatabaseMetaData.locatorsUpdateCopies() ). Debido a eso, debe usar el correspondiente PreparedStatement.setBlob() o ResultSet.updateBlob() (en el caso de conjuntos de resultados actualizables) para guardar cambios en la base de datos.

    A partir de Connector/J versión 3.1.0, puede emular Blobs con localizadores añadiendo la propiedad 'emulateLocators=true' en la URL de JDBC . Debe usar un alias de columna con el valor de la columna asignado con el nombre real de la columna Blob. El SELECT debe referenciar sólo a una tabla, la tabla debe tener una clave primaria, y el SELECT debe cubrir todas las columnas que forman la clave primaria. El driver retardará cargar los datos Blob hasta que reciba los métodos Blob (getInputStream(), getBytes(), etc) .

  • CallableStatement

    Desde Connector/J 3.1.1, los procedimientos almacenados se soportan al conectar a MySQL versión 5.0 o posterior via la interfaz . Actualmente no se soporta el método de .

  • Clob

    La implementación Clob no permite moficicación in-situ (hay 'copias', como se explica en el método DatabaseMetaData.locatorsUpdateCopies() ). Debido a esto, debe usar el método PreparedStatement.setClob() para salvar los cambios en la base de datos. La API JDBC no tiene un método ResultSet.updateClob().

  • Connection

    Diferentemente a otras versiones de MM.MySQL el método 'isClosed()' no hace "ping" al servidor para determinar si está vivo. En concordancia con la especificación JDBC , sólo retorna cierto si se ha llamado a 'closed()' en la conexión. Si necesita determinar si la conexión todavía es válida, debe realizar una consulta simple, como "SELECT 1". El driver lanzará una excepción si la conexión no sigue siendo válida.

  • DatabaseMetaData

    Clave sobre la clave forana (getImported/ExportedKeys() y getCrossReference()) sólo está disponible de tablas tipo 'InnoDB'. Sin embargo, el driver usa 'SHOW CREATE TABLE' para recibir esta información, así que cuando otros tipos de tabla soportan claves foráneas, el driver las soporta también transparentemente.

  • Driver

  • PreparedStatement

    PreparedStatements se implementan por el driver, ya que MySQL no tiene la característica de comandos preparados. Debido a ello, el driver no implementa getParameterMetaData() o getMetaData() como requiere el driver para tener un parser SQL completo en el cliente.

    A partir de la versión 3.1.0 MySQL Connector/J, los comandos preparados en el servidor y los conjuntos de resultados con codificación binaria se usan cuando lo soporta el servidor.

    Tenga cuidado al usar comandos preparados en el servidor con parámetros "grandes" que se asignan via setBinaryStream(), setAsciiStream(), setUnicodeStream(), setBlob(), o setClob(). Si quiere re-ejecutar el comando con cualquier parámetro "grande" cambiado a un parámetro no-"grande", es necesario llamar a clearParameters() y asignar todos los parámetros de nuevo. La razón es la siguiente:

    • El driver envía los datos 'grandes' al comando preparado en el servidor por otro lado cuando se asigna un valor al parámetro (antes de la ejecución del parámetro preparado).

    • Una vez hecho esto, el flujo usado para leer los datos en el lado del cliente se cierra (por la especificación de JDBC), y no puede leerse de nuevo.

    • Si un parámetro cambia de un valor "grande" a uno no-"grande", el driver debe resetear el estado del servidor del comando preparado para permitir al parámetro que ha cambiado tomar el valor del valor "grande" anterior. Esto elimina todos los datos 'grandes' que se han enviado al servidor, por lo tanto requiriendo que los datos se vuelvan a enviar, via los métodos setBinaryStream(), setAsciiStream(), setUnicodeStream(), setBlob() o setClob() .

    Consecuentemente, si quiere cambiar el "tipo" de un parámetro a uno no-"grande", debe llamar clearParameters() y asignar todos los parámetros del comando preparado de nuevo antes que pueda ser re-ejecutado.

  • ResultSet

    Por defecto, los ResultSets se reciben completamente y se almacenan en memoria. En la mayoría de casos, esta es la forma más eficiente de operar, y debido al diseño del protocolo de red de MySQL es más fácil de implementar. Si está trabando con ResultSets que tienen un gran número de registros o valores grandes, y no puede reservar espacio en su JVM para la memoria requerida, puede decirle al driver que 'envíe mediante un flujo' los resultados de vuelta registro a registro.

    Para permititr esta funcionalidad, necesita crear una instancia de Statement de la siguiente manera:

    stmt = conn.createStatement(java.sql.ResultSet.TYPE_FORWARD_ONLY,
                  java.sql.ResultSet.CONCUR_READ_ONLY);
    stmt.setFetchSize(Integer.MIN_VALUE);

    La combinación de un conjunto de resultados de sólo lectura, con un tamaño de Integer.MIN_VALUE sirve como señal al driver para "stream" conjunto de resultados registro a registro. Tras esto cualquier conjunto de resultados creado con el comando se recibe registro a registro.

    Hay algunas lagunas con esta aproximación. Tiene que leer todos los registros en el conjunto de resultados (o cerrarlo) antes que pueda realizar ninguna otra consulta con la conexión, o se lanzará una excepción.

    El primero de los bloqueos que tratan estos comandos puede liberarse (sean bloqueos de tabla MyISAM o bloqueos a nivel de registro en cualquier otro motor de almacenamiento como InnoDB) cuando se completa el comando.

    Si el comando está en una transacción, entonces los bloqueos se liberan cuando se completa (lo que implica que el comando necesita completarse antes). Como con la mayoría de las otras bases de datos, los comandos no se completan hasta que todos los resultados pendientes en el comando se leen o el conjunto de resultados activo para el comando se cierra.

    Por lo tanto, si usa resultados "streaming", debe procesarlos tan rápido como sea posible si quiere mantener aceso concurrente a las tablas referenciadas por el comando que produce el conjunto de resultados.

  • ResultSetMetaData

    El método "isAutoIncrement()" sólo funciona con MySQL servers 4.0 y posterior.

  • Statement

    Al usar versiones del driver JDBC anteriores a 3.2.1, y conectado a versiones del servidor anteriores a 5.0.3, el método "setFetchSize()" no tiene efecto, otro que tratar el streaming del conjunto de resultados como se describe anteriormente.

    MySQL no soporta cursores SQL, y el driver JDBC no los emula, así que "setCursorName()" no tiene efecto.

25.3.3.3. Java, JDBC y tipos MySQL

MySQL Connector/J es flexible en el sentido que trata conversiones entre tipos de datos MySQL y tipos de datos Java .

En general, cualquier tipo de datos MySQL puede convertirse a java.lang.String, y cualquier tipo numérico puede convertirse a cualquier tipo de datos numérico de Java, aunque puede haber redondeo, overflow o pérdida de precisión.

A partir de Connector/J 3.1.0, el driver JDBC realiza advertencias o lanza excepciones DataTruncation como requier la especificación JDVC a no ser que la conexión se configure para no hacerlo con la propiedad "jdbcCompliantTruncation" a "false".

Las conversiones que siempre se garantizan que funcionan se muestran en la siguiente tabla:

Tabla 25.2. Tabla de conversiones

Estos tipos de datos MySQL Siempre pueden convertirse en tipos de datos Java
CHAR, VARCHAR, BLOB, TEXT, ENUM, and SET
FLOAT, REAL, DOUBLE PRECISION, NUMERIC, DECIMAL, TINYINT, SMALLINT, MEDIUMINT, INTEGER, BIGINT

Nota

puede ocurrir redondeo, overflow o pérdida de precisión si elige tipos de datos numéricos Java que tengan menos precisión o capacidad que los tipos de datos MySQL que se convierten.

DATE, TIME, DATETIME, TIMESTAMP

El método usa la siguiente conversión de tipos entre MySQL y tipos Java, siguiendo la especificación JDBC donde es apropiado:

Tabla 25.3. Tipos MySQL para tiposJava Types para ResultSet.getObject()

Nombre de tipo MySQL Retornado como Java Class
BIT(1) (nuevo en MySQL-5.0)
BIT( > 1) (nuevo en MySQL-5.0)
TINYINT si la propiedad de configuración "tinyInt1isBit" está a "true" (por defecto) y el tamaño de almacenamiento es "1", o si no.
BOOL , BOOLEAN Consulte TINYINT , anteriores son alias para TINYINT(1) , actualmente.
SMALLINT[(M)] [UNSIGNED] (sea UNSIGNED o no)
MEDIUMINT[(M)] [UNSIGNED] (sea UNSIGNED o no)
INT,INTEGER[(M)] [UNSIGNED] , si UNSIGNED
BIGINT[(M)] [UNSIGNED] , si UNSIGNED
FLOAT[(M,D)]
DOUBLE[(M,B)]
DECIMAL[(M[,D])]
DATE
DATETIME
TIMESTAMP[(M)]
TIME
YEAR[(2|4)] (con la fecha a 1 de Enero, a media noche)
CHAR(M) (a no ser que el conjunto de carácteres para la columna sea BINARY , entonces se retorna .
VARCHAR(M) [BINARY] (a no ser que el conjunto de carácteres para la columna sea BINARY , entonces se retorna .
BINARY(M)
VARBINARY(M)
TINYBLOB
TINYTEXT
BLOB
TEXT
MEDIUMBLOB
MEDIUMTEXT
LONGBLOB
LONGTEXT
ENUM('value1','value2',...)
SET('value1','value2',...)

25.3.3.4. Usando conjuntos de carácteres y Unicode

Todas las cadenas de carácteres enviadas desde el driver JDBC al servidor se convierten automáticament de Unicode nativo Java a la codificación de carácteres del cliente, incluyendo todas las consultas enviadas via , , así como y parámetros con la exclusión de parámentros usando , , , y .

Antes de MySQL Server 4.1, Connector/J soporta una codificación de carácteres por conexión, que puede detectarse automáticamente de la configuración del servidor, o puede configurarse con las propiedades y .

A partir de MySQL Server 4.1, Connector/J soporta una sóla codificación de carácteres entre cliente y servidor, y cualquier número de codificación de carácteres para datos retornados por el servidor al cliente en .

La codificación de carácteres entre cliente y servidor se detecta automáticamente en la conexión. La codificación usada por el driver se especifica en el servidor via la variable de configuración ' ' para versiones anteriores a 4.1.0 y ' ' para versiones de servidor 4.1.0 y posteriores. Consulte "Conunto de carácteres del servidor y colaciones" en el manual de servidor MySQL para más información.

Para aliminar la detección automática de codificación en el cliente, use la propiedad en la URL usada para conectar al sevidor.

Cuando especifique codificaciones de carácteres en el cliente, deben usarse nombres de estilo Java. La siguiente tabla lista nombres de estilo Java para conjuntos de carácters MySQL:

Tabla 25.4. Traducción MySQL a nombres codificación Java

Nombre de conjunto de carácteres MySQL Nombre codificación carácter estilo java Java
usa7 US-ASCII
big5 Big5
gbk GBK
sjis SJIS
gb2312 EUC_CN
ujis EUC_JP
euc_kr EUC_KR
latin1 ISO8859_1
latin1_de ISO8859_1
german1 ISO8859_1
danish ISO8859_1
latin2 ISO8859_2
czech ISO8859_2
hungarian ISO8859_2
croat ISO8859_2
greek ISO8859_7
hebrew ISO8859_8
latin5 ISO8859_9
latvian ISO8859_13
latvian1 ISO8859_13
estonia ISO8859_13
dos Cp437
pclatin2 Cp852
cp866 Cp866
koi8_ru KOI8_R
tis620 TIS620
win1250 Cp1250
win1250ch Cp1250
win1251 Cp1251
cp1251 Cp1251
win1251ukr Cp1251
cp1257 Cp1257
macroman MacRoman
macce MacCentralEurope
utf8 UTF-8
ucs2 UnicodeBig

Aviso

No realice la consulta 'set names' con Connector/J, ya que el driver no detectará que ha cambiado el conjunto de carácteres, y continuarña usando el conjunto de carácteres detectado durante la inicialización de la conexión.

Para permitir enviar múltiples conjuntos de carácters del cliente, debe usarse codificación "UTF-8", configurando "utf8" como el conjunto de carácteres por defecto del servidor, o configurando el driver JDBC para usar "UTF-8" con la propiedad .

25.3.3.5. Conexión segura con SSL

SSL en MySQL Connector/J encripta todos los datos (otros que no sean la negociación inicial) entre el driver JDBC y el servidor. La penalización al rendimiento para permitir SSL es un incremento en tiempo de proceso de consulta entre el 35% y el 50%, dependiendo del tamaño de la consulta, y la cantidad de datos que retorna.

Para que funcione el soporte SSL, debe tener lo siguiente:

Necesitará primeramente importar el certificado CA Certificate de MySQL en una entidad de confianza Java. Un certificado CA de ejemplo está en el subdirectorio 'SSL' de la distribución fuente de MySQL. Esto es lo que usa SSL para determinar si está comunicando con un servidor MySQL seguro.

Usar 'keytool' de Java para crear una entidad de confianza en el directorio actual, e importar el certificado CA del servidor ('cacert.pem'), puede hacer lo siguiente (asumiendo que 'keytool' está en su ruta. Está localizado en el subdirectorio 'bin' de su JDK o JRE):

shell> keytool -import -alias mysqlServerCACert -file cacert.pem -keystore truststore
        

Keytool responde con la siguiente información:

Enter keystore password:  *********
Owner: [email protected], CN=Walrus, O=MySQL AB, L=Orenburg, ST=Some
-State, C=RU
Issuer: [email protected], CN=Walrus, O=MySQL AB, L=Orenburg, ST=Som
e-State, C=RU
Serial number: 0
Valid from: Fri Aug 02 16:55:53 CDT 2002 until: Sat Aug 02 16:55:53 CDT 2003
Certificate fingerprints:
         MD5:  61:91:A0:F2:03:07:61:7A:81:38:66:DA:19:C4:8D:AB
         SHA1: 25:77:41:05:D5:AD:99:8C:14:8C:CA:68:9C:2F:B8:89:C3:34:4D:6C
Trust this certificate? [no]:  yes
Certificate was added to keystore

Necesitará generar un certificado de cliente, para que el servidor MySQL conozca que habla con un cliente seguro:

 shell> keytool -genkey -keyalg rsa -alias mysqlClientCertificate -keystore keystore 

Keytool le pide la siguiente información, y crea una llave llamada 'keystore' en el directorio actual.

Debe responder con información apropiada para su situación:

Enter keystore password:  *********
What is your first and last name?
  [Unknown]:  Matthews
What is the name of your organizational unit?
  [Unknown]:  Software Development
What is the name of your organization?
  [Unknown]:  MySQL AB
What is the name of your City or Locality?
  [Unknown]:  Flossmoor
What is the name of your State or Province?
  [Unknown]:  IL
What is the two-letter country code for this unit?
  [Unknown]:  US
Is <CN=Matthews, OU=Software Development, O=MySQL AB,
 L=Flossmoor, ST=IL, C=US> correct?
  [no]:  y

Enter key password for <mysqlClientCertificate>
        (RETURN if same as keystore password):

Finalmente, para decir a JSSE que use la llave y entidad de confianza creadas, necesita asignar las siguientes propiedades de sistema cuando arranaca JVM, replazando 'path_to_keystore_file' con la ruta completa al fichero de la clave que ha creado, y usando la contraseña apropiada para cada propiedad.

-Djavax.net.ssl.keyStore=path_to_keystore_file
-Djavax.net.ssl.keyStorePassword=*********
-Djavax.net.ssl.trustStore=path_to_truststore_file
-Djavax.net.ssl.trustStorePassword=********* 

Necesita asignar a 'useSSL' 'true' en sus parámetros de conexión para MySQL Connector/J, añadiendo 'useSSL=true' a la URL, o poniendo la propiedad 'useSSL' a 'true' en la instancia java.util.Properties que pasa a DriverManager.getConnection().

Puede testear que SSL está funcionando activando la depuración de JSSE (como se detalla a contiunación), y buscar por los eventos clave siguientes:

...
 *** ClientHello, v3.1
 RandomCookie:  GMT: 1018531834 bytes = { 199, 148, 180, 215, 74, 12, 54, 244, 0, 168, 55, 103, 215, 64, 16, 138, 225, 190, 132, 153, 2, 217, 219, 239, 202, 19, 121, 78 }
 Session ID:  {}
 Cipher Suites:  { 0, 5, 0, 4, 0, 9, 0, 10, 0, 18, 0, 19, 0, 3, 0, 17 }
 Compression Methods:  { 0 }
 ***
 [write] MD5 and SHA1 hashes:  len = 59
 0000: 01 00 00 37 03 01 3D B6   90 FA C7 94 B4 D7 4A 0C  ...7..=.......J.
 0010: 36 F4 00 A8 37 67 D7 40   10 8A E1 BE 84 99 02 D9  6...7g.@........
 0020: DB EF CA 13 79 4E 00 00   10 00 05 00 04 00 09 00  ....yN..........
 0030: 0A 00 12 00 13 00 03 00   11 01 00                 ...........
 main, WRITE:  SSL v3.1 Handshake, length = 59
 main, READ:  SSL v3.1 Handshake, length = 74
 *** ServerHello, v3.1
 RandomCookie:  GMT: 1018577560 bytes = { 116, 50, 4, 103, 25, 100, 58, 202, 79, 185, 178, 100, 215, 66, 254, 21, 83, 187, 190, 42, 170, 3, 132, 110, 82, 148, 160, 92 }
 Session ID:  {163, 227, 84, 53, 81, 127, 252, 254, 178, 179, 68, 63, 182, 158, 30, 11, 150, 79, 170, 76, 255, 92, 15, 226, 24, 17, 177, 219, 158, 177, 187, 143}
 Cipher Suite:  { 0, 5 }
 Compression Method: 0
 ***
 %% Created:  [Session-1, SSL_RSA_WITH_RC4_128_SHA]
 ** SSL_RSA_WITH_RC4_128_SHA
 [read] MD5 and SHA1 hashes:  len = 74
 0000: 02 00 00 46 03 01 3D B6   43 98 74 32 04 67 19 64  ...F..=.C.t2.g.d
 0010: 3A CA 4F B9 B2 64 D7 42   FE 15 53 BB BE 2A AA 03  :.O..d.B..S..*..
 0020: 84 6E 52 94 A0 5C 20 A3   E3 54 35 51 7F FC FE B2  .nR..\ ..T5Q....
 0030: B3 44 3F B6 9E 1E 0B 96   4F AA 4C FF 5C 0F E2 18  .D?.....O.L.\...
 0040: 11 B1 DB 9E B1 BB 8F 00   05 00                    ..........
 main, READ:  SSL v3.1 Handshake, length = 1712
 ...

JSSE proporciona depuración (a STDOUT) cuando asigna las siguientes propiedades de sistema: -Djavax.net.debug=all Este lo dice que claves y entidades de confianza se usan, así como que ocurre durante el intercambio SSL e intercambio de certificados. Será útil al determinar qué no está funcionando cuando se intenta realizar una conexión SSL.

25.3.3.6. Usando replicación Maestro/Esclavo con ReplicationConnection

A partir de Connector/J 3.1.7, está disponible una variante del driver que envía automáticamente consultas a un maestro de lectura/escritura, o un fallo o conjunto de esclavos con carga balanceada mediante round-robin basado en el estado de .

Una aplicación señala que quiere que una transacción sea sólo de lectura llamando , esta conexión "avisada de replicación" usará una de las conexiones esclavas, que están balanceadas por vm usando un esquema round-robin (una conexión dada se "pega" a un esclavo a no ser que se quite al esclavo del servicio). Si tiene una transacción de lectura, la replicación de MySQL es asíncrona), asigne que la conexión no sea sólo de lectura, llamando y el driver se asegura que las siguientes llamadas se envíen al sevidor MySQL "maestro". El driver tiene cuidado de propagar el estado actual de autocommit, nivel de isolación, y catálogos entre todas las conexiones que usa para complir la funcionalidad de balanceo de carga.

Para activar esta funcionalidad, use la clase " " al configurar su pool de conexiones del servidor de aplicaciones o al crear una instancia de un driver JDBC para su aplicación autónoma. Como acepta el mismo formato de URL que el driver estándar JDBC MySQL, no funciona con creación de conexiones basadas en a no ser que sea el único driver JDBC de MySQL registrado con .

Aquí hay un pequeño ejemplo sobre cómo puede usarse ReplicationDriver en una aplicación autónoma.

import java.sql.Connection;
import java.sql.ResultSet;
import java.util.Properties;

import com.mysql.jdbc.ReplicationDriver;

public class ReplicationDriverDemo {

    public static void main(String[] args) throws Exception {
        ReplicationDriver driver = new ReplicationDriver();

        Properties props = new Properties();

        // We want this for failover on the slaves
        props.put("autoReconnect", "true");

        // We want to load balance between the slaves
        props.put("roundRobinLoadBalance", "true");

        props.put("user", "foo");
        props.put("password", "bar");

        //
        // Looks like a normal MySQL JDBC url, with a comma-separated list
        // of hosts, the first being the 'master', the rest being any number
        // of slaves that the driver will load balance against
        //

        Connection conn =
            driver.connect("jdbc:mysql://master,slave1,slave2,slave3/test",
                props);

        //
        // Perform read/write work on the master
        // by setting the read-only flag to "false"
        //

        conn.setReadOnly(false);
        conn.setAutoCommit(false);
        conn.createStatement().executeUpdate("UPDATE some_table ....");
        conn.commit();

        //
        // Now, do a query from a slave, the driver automatically picks one
        // from the list
        //

        conn.setReadOnly(true);

        ResultSet rs = conn.createStatement().executeQuery("SELECT a,b,c FROM some_other_table");

         .......
    }
}

25.3.4. Usando Connector/J con J2EE y otros Java Frameworks

Esta sección describe cómo usar Connector/J en varios contextos.

25.3.4.1. Conceptos generales J2EE

Esta sección proporciona transfondo general de conceptos de J2EE que usan el Connector/J.

25.3.4.1.1. Entendiendo los pool de conexiones

Crear pools de conexiones es la técnica de crear y administrar un conjunto de conexiones preparados para usar por cualquier flujo que lo necesite.

La técnica de "pooling" conexiones se basa en el hecho que la mayoría de aplicaciones sólo necesitan que un flujo tenga acceso a una conexión JDBC cuando procesan activamente una transacción, lo que usualmente sólo tarda milisegundos en completarse. Cuando no procesan una transacción, la conexión queda en espera. En su lugar, un pool de conexiones permite que la conexión inactiva sea usada por otro flujo para hacer trabajo útil.

En la práctica, cuando un flujo necesita trabajar contra MySQL u otra base de datos con JDBC, pide una conexión al pool. Cuando el flujo finaliza el uso de la conexión, la retorna el pool para que pueda ser usada por cualquier otro flujo que la necesite.

Cuando una conexión se "alquila" en el pool, la usa únicamente el flujo que la pide. Desde un punto de vista de programación, es lo mismo que si su flujo llame a DriverManager.getConnection() cada vez que necesite una conexión JDBC, sin embargo con el pool de conexiones, su flujo puede acabar usando una conexión nueva o ya existente.

Los pool de conexiones pueden incrementar el rendimiento de su aplicación Java, y reducir el uso de recursos global. Los mayores beneficios de los pool de conexiones son:

  • Reducir el tiempo de creación de conexiones

    Aunque normalmente no es un tema proecupante ya que MySQL ofrece un tiempo de incialización rápido en comparación con otras bases de datos, la creación de conexiones JDBC todavía incurre en la sobrecarga de red y conexiones JDBC que se eliminan si se "reciclan" las conexiones.

  • Modelo de programación simplificado

    Usando pools de conexiones, cada flujo individual puede actuar como si hubiese creado su propia conexión JDBC, permitiendo usar ténicas de programación JDBC directas.

  • Uso de recursos controlado

    Si no usa pools de conexiones, y en su lugar crea una nueva conexión cada vez que un flujo necesita una, su uso de recursos por parte de la aplicación puede ser muy derrochador y puede llevar a comportamiento impredictible bajo carga.

Recuerde que cada conexión de MySQL tiene sobrecarga (memoria, CPU, cambios de contexto, etc) tanto en el cliente como en el servidor. Cada conexión limita los recursos disponible para su aplicación así como el servidor MySQL. Muchos de estos recursos se usarán tanto si la conexión está haciendo un trabajo útil como si no!

Los pools de conexiones pueden ajustarse para maximizar el rendimiento, mientras que mantienen la utilización de recursos bajo el punto en que su aplicación empieza a fallar en lugar de sólo ir más lenta.

Afortunadamente, Sun ha estandarizado el concepto de pool de conexiones en JDBC a través de las interficies "opcionales" JDBC-2.0 y todos los servidores de aplicaciones tienen implementaciones de estas APIs que funcionan bien con MySQL Connector/J.

Generalmente, usted configura un pool de conexiones en su servidor de aplicaciones en sus ficheros de configuración del servidor, y accede via el Java Naming y Directory Interface (JNDI). El siguiente código muestra cómo puede usar un pool de conexiones desde una aplicación desplegada en un servidor de aplicaciones J2EE:

Ejemplo 25.12. Usando un pool de conexiones con un servidor de aplicaciones J2EE

import java.sql.Connection;
import java.sql.SQLException;
import java.sql.Statement;

import javax.naming.InitialContext;
import javax.sql.DataSource;


public class MyServletJspOrEjb {

    public void doSomething() throws Exception {
        /*
         * Create a JNDI Initial context to be able to
         *  lookup  the DataSource
         *
         * In production-level code, this should be cached as
         * an instance or static variable, as it can
         * be quite expensive to create a JNDI context.
         *
         * Note: This code only works when you are using servlets
         * or EJBs in a J2EE application server. If you are
         * using connection pooling in standalone Java code, you
         * will have to create/configure datasources using whatever
         * mechanisms your particular connection pooling library
         * provides.
         */

        InitialContext ctx = new InitialContext();

         /*
          * Lookup the DataSource, which will be backed by a pool
          * that the application server provides. DataSource instances
          * are also a good candidate for caching as an instance
          * variable, as JNDI lookups can be expensive as well.
          */

        DataSource ds = (DataSource)ctx.lookup("java:comp/env/jdbc/MySQLDB");

        /*
         * The following code is what would actually be in your
         * Servlet, JSP or EJB 'service' method...where you need
         * to work with a JDBC connection.
         */

        Connection conn = null;
        Statement stmt = null;

        try {
            conn = ds.getConnection();

            /*
             * Now, use normal JDBC programming to work with
             * MySQL, making sure to close each resource when you're
             * finished with it, which allows the connection pool
             * resources to be recovered as quickly as possible
             */

            stmt = conn.createStatement();
            stmt.execute("SOME SQL QUERY");

            stmt.close();
            stmt = null;

            conn.close();
            conn = null;
        } finally {
            /*
             * close any jdbc instances here that weren't
             * explicitly closed during normal code path, so
             * that we don't 'leak' resources...
             */

            if (stmt != null) {
                try {
                    stmt.close();
                } catch (sqlexception sqlex) {
                    // ignore -- as we can't do anything about it here
                }

                stmt = null;
            }

            if (conn != null) {
                try {
                    conn.close();
                } catch (sqlexception sqlex) {
                    // ignore -- as we can't do anything about it here
                }

                conn = null;
            }
        }
    }
}

Como se muestra en el ejemplo anterior, tras obtener el JNDI InitialContext, y buscar en el DataSource, el resto del código debe parecer familiar a cualquiera que haya programado JDBC en el pasado.

Lo más importante a recordar al usar pools de conexiones es asegurarse que no importa qué ocurra en su código (excepciones, control de flujo, etc), conexiones, y cualquier cosa creada por ellas (comandos, conjuntos de resultados, etc) se cierran, así que pueden ser reusados, de otro modo serán "trenzados", lo que en el mejor caso significa que los recursos que el servidor MySQL representa (búffers, bloqueos, sockets, etc) pueden quedar atados por algún tiempo, o en el peor de los casos, atados para siempre.

¿Cuál es el mejor tamaño para mi pool de conexiones?

Como con todas las otras reglas de configuración, la respuesta es "depende". Mientras el tamaño óptimo depende de carga anticipada y tiempo medio de transacción de la base de datos, el tamaño del pool de conexiones óptimo es menor de lo que podría esperar. Si toma la aplicación de Sun Java Petstore de ejemplo, un pool de conexiones de 15-20 conexiones puede servir una carga moderada (600 usuarios concurrentes) usando MySQL y Tomcat con tiempos de respuesta aceptables.

Para poner el tamaño correcto en un pool de conexiones para su aplicación, debe crear tests de carga con herramientas como Apache JMeter o The Grinder, y testear su aplicación.

Una forma sencilla de determinar un punto de inicio es configurar su pool de conexión con un número máximo de conexiones "ilimitado", ejecutar un test de carga, y medir el máximo número de conexiones de usuario concurrentes. Puede trabajar a partir de aquí para determinar los valores de conexiones máximo y mínimo dado el mejor rendimiento de su aplicación.

25.3.4.2. Usando Connector/J con Tomcat

Las siguientes instrucciones se basan en las instrucciones para Tomcat-5.x, disponibles en http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jndi-datasource-examples-howto.html que es la actual en el momento de escritura de este documento.

Primero, instale el fichero .jar que viene con Connector/J en para que esté disponible para todas las aplicaciones instaladas en el contenedor.

A continuación, Configure JNDI DataSource añadiendo una declaración de recurso en en el contexto que define su aplicación web:

<Context ....>

  ...

  <Resource name="jdbc/MySQLDB"
               auth="Container"
               type="javax.sql.DataSource"/>

  <!-- The name you used above, must match _exactly_ here!

       The connection pool will be bound into JNDI with the name
       "java:/comp/env/jdbc/MySQLDB"
  -->

  <ResourceParams name="jdbc/MySQLDB">
    <parameter>
      <name>factory</name>
      <value>org.apache.commons.dbcp.BasicDataSourceFactory</value>
    </parameter>

    <!-- Don't set this any higher than max_connections on your
         MySQL server, usually this should be a 10 or a few 10's
         of connections, not hundreds or thousands -->

    <parameter>
      <name>maxActive</name>
      <value>10</value>
    </parameter>

    <!-- You don't want to many idle connections hanging around
         if you can avoid it, only enough to soak up a spike in
         the load -->

    <parameter>
      <name>maxIdle</name>
      <value>5</value>
    </parameter>

    <!-- Don't use autoReconnect=true, it's going away eventually
         and it's a crutch for older connection pools that couldn't
         test connections. You need to decide if your application is
         supposed to deal with SQLExceptions (hint, it should), and
         how much of a performance penalty you're willing to pay
         to ensure 'freshness' of the connection -->

    <parameter>
      <name>validationQuery</name>
      <value>SELECT 1</value>
    </parameter>

   <!-- The most conservative approach is to test connections
        before they're given to your application. For most applications
        this is okay, the query used above is very small and takes
        no real server resources to process, other than the time used
        to traverse the network.

        If you have a high-load application you'll need to rely on
        something else. -->

    <parameter>
      <name>testOnBorrow</name>
      <value>true</value>
    </parameter>

   <!-- Otherwise, or in addition to testOnBorrow, you can test
        while connections are sitting idle -->

    <parameter>
      <name>testWhileIdle</name>
      <value>true</value>
    </parameter>

    <!-- You have to set this value, otherwise even though
         you've asked connections to be tested while idle,
         the idle evicter thread will never run -->

    <parameter>
      <name>timeBetweenEvictionRunsMillis</name>
      <value>10000</value>
    </parameter>

    <!-- Don't allow connections to hang out idle too long,
         never longer than what wait_timeout is set to on the
         server...A few minutes or even fraction of a minute
         is sometimes okay here, it depends on your application
         and how much spikey load it will see -->

    <parameter>
      <name>minEvictableIdleTimeMillis</name>
      <value>60000</value>
    </parameter>

    <!-- Username and password used when connecting to MySQL -->

    <parameter>
     <name>username</name>
     <value>someuser</value>
    </parameter>

    <parameter>
     <name>password</name>
     <value>somepass</value>
    </parameter>

    <!-- Class name for the Connector/J driver -->

    <parameter>
       <name>driverClassName</name>
       <value>com.mysql.jdbc.Driver</value>
    </parameter>

    <!-- The JDBC connection url for connecting to MySQL, notice
         that if you want to pass any other MySQL-specific parameters
         you should pass them here in the URL, setting them using the
         parameter tags above will have no effect, you will also
         need to use &amp; to separate parameter values as the
         ampersand is a reserved character in XML -->

    <parameter>
      <name>url</name>
      <value>jdbc:mysql://localhost:3306/test</value>
    </parameter>

  </ResourceParams>
</Context>

En general, debe usar las instrucciones de instalación que vienen con su versión de Tomcat, ya que la forma de configurar fuentes de datos en Tomcat cambian de vez en cuando, y si usa la sintaxis equivocada en el fichero XML, puede acabar con una excepción similar a la siguiente:

Error: java.sql.SQLException: Cannot load JDBC driver class 'null ' SQL
state: null 

25.3.4.3. Usando Connector/J con JBoss

Estas instrucciones cubren JBoss-4.x. Para hacer que las clases del driver JDBC estén disponibles para el servidor de aplicaciones, copie el fichero .jar que viene con el Connector/J en el directorio para su configuración del servidor (normalmente llamada ""). A continuación, en el mismo directorio de configuración, en el subdirectorio llamado "deploy", cree un fichero de configuración de fuente de datos que acabe con "-ds.xml", que le dice a JBoss que despliegue este fichero como JDBC Datasource. El fichero debe tener el siguiente contenido:

<datasources>
    <local-tx-datasource>
        <!-- This connection pool will be bound into JNDI with the name
             "java:/MySQLDB" -->

        <jndi-name>MySQLDB</jndi-name>
        <connection-url>jdbc:mysql://localhost:3306/dbname</connection-url>
        <driver-class>com.mysql.jdbc.Driver</driver-class>
        <user-name>user</user-name>
        <password>pass</password>

        <min-pool-size>5</min-pool-size>

        <!-- Don't set this any higher than max_connections on your
         MySQL server, usually this should be a 10 or a few 10's
         of connections, not hundreds or thousands -->

        <max-pool-size>20</max-pool-size>

        <!-- Don't allow connections to hang out idle too long,
         never longer than what wait_timeout is set to on the
         server...A few minutes is usually okay here,
         it depends on your application
         and how much spikey load it will see -->

        <idle-timeout-minutes>5</idle-timeout-minutes>

        <!-- If you're using Connector/J 3.1.8 or newer, you can use
             our implementation of these to increase the robustness
             of the connection pool. -->

        <exception-sorter-class-name>com.mysql.jdbc.integration.jboss.ExtendedMysqlExceptionSorter</exception-sorter-class-name>
        <valid-connection-checker-class-name>com.mysql.jdbc.integration.jboss.MysqlValidConnectionChecker</valid-connection-checker-class-name>

    </local-tx-datasource>
</datasources> 

25.3.5. Diagnóstico de problemas de Connector/J

Esta sección describe cómo arreglar problemas que puede encontrar al usar Connector/J.

25.3.5.1. Problemas comunes y soluciones

Hay algunos temas que parecen encontrar los usuarios de MySQL Connector/J. Esta sección trata sus síntomas y su resolución. Si tiene otros problemas, consulte la sección "SOPORTE".

26.3.5.1.1:

Question:

Cuando intento conectar a la base de datos con MySQL Connector/J, obtengo la siguiente excepción:

SQLException: Server configuration denies access to data source
SQLState: 08001
VendorError: 0

¿Qué ocurre? Puede conectar bien con el cliente de línea de comandos de MySQL.

Answer:

MySQL Connector/J usa sockets TCP/IP para conectar a MySQL, ya que Java no soporta Unix Domain Sockets. Por lo tanto, cuando MySQL Connector/J conecta a MySQL, el administrador de seguridad en el servidor MySQL usará sus tablas de permisos para determinar si la conexión debe permitirse.

Debe añadir permisos para permitir esto. Lo siguiente es un ejemplo de cómo hacerlo (pero no es lo más seguro).

Desde el cliente de línea de comandos, logueado como usuario que pueda otorgar privilegios, ejecute el siguiente comando:

GRANT ALL PRIVILEGES ON [dbname].* to
                '[user]'@'[hostname]' identified by
                '[password]'

reemplazando [dbname] con el nombre de su base de datos, [user] con el nombre de usuario, [hostname] con el equipo desde el que se conecta MySQL Connector/J , y [password] con la contraseña que quiere usar. Tenga en cuenta que RedHat Linux está roto respecto a la porción de nombre de equipo para el caso en que conecte desde el equipo local. Necesita usar "localhost.localdomain" para el valor [hostname] en este caso. A continuación ejecute el comando "FLUSH PRIVILEGES".

Nota

Compruebe su conectividad con el cliente de línea de comandos "mysql", pero no funcionará a no ser que añada el flag "--host" y use un valor distinto a "localhost" para el equipo. Si está testeando la conectividad con "localhost", use "127.0.0.1" como nombre de equipo.

Aviso

Si no entiende lo que hace el comando 'GRANT' o cómo funciona, debe leer y entender la sección 'Temas generales de seguridad y el sistema de privilegios de acceso de MySQL' del manual MySQL antes de intentar cambiar los premisos.

Cambiar privilegios y permisos de forma no correcta en MySQL puede causar que su instalación no tenga propiedades de seguridad óptimas.

26.3.5.1.2:

Question:

Mi aplicación lanza una SQLException 'No Suitable Driver'. ¿Qué ocurre?

Answer:

Pueden ser dos cosas. O el driver no está en su CLASSPATH (consulte la sección "INSTALACIÓN" anterior), o su formato de URL no es correcto (consulte "Desarrollo de aplicaciones con MySQL Connector/J").

26.3.5.1.3:

Question:

Intento usar MySQL Connector/J en un applet o aplicación y obtengo una excepción similar a:

SQLException: Cannot connect to MySQL server on host:3306.
Is there a MySQL server running on the machine/port you
are trying to connect to?

(java.security.AccessControlException)
SQLState: 08S01
VendorError: 0 

Answer:

Incluso si está ejecutando un Applet, su MySQL server ha sido instalado con la opción "--skip-networking" activada, o su MySQL server tiene un firewall delante.

Applets sólo pueden hacer conexiones de red de vuelta a la máquina que ejecuta el servidor web que sirve los ficheros .class para el applet. Esto significa que MySQL debe ejecutarse en la misma máquina (o debe tener alguna clase de redirección de puertos) para que funcione. También significa que no será capaz de testear applets en su sistema de ficheros local, siempre debe desplegarlos en un servidor web.

MySQL Connector/J sólo puede comunicar con MySQL usando TCP/IP, ya que Java no soporta sockets de dominio Unix. La comunicación TCP/IP con MySQL puede verse afectada si MySQL se arranca con el flag "--skip-networking" , o si tiene un firewall.

Si MySQL se arranca con la opción "--skip-networking" activada (el paquete Debian Linux de MySQL server lo hace, por ejemplo), necesita comentarlo en los ficheros /etc/mysql/my.cnf o /etc/my.cnf. Por supuesto, su fichero my.cnf puede existir en el directorio "data" de su MySQL server, o en cualquier otro sitio (en función de cómo se compiló MySQL en su sistema). Los binarios creados por MySQL AB siempre buscan en /etc/my.cnf y [datadir]/my.cnf. Si su MySQL tiene un firewall, necesitará tener el firewall configurado para permitir conexiones TCP/IP desde el equipo donde el código Java está corriendo al servidor MySQL en el puerto en el que está escuchando MySQL (por defecto 3306).

26.3.5.1.4:

Question:

Tengo un servlet/aplicación que funciona bien durante un día y para de funcionar por la noche

Answer:

MySQL cierra las conexiones tras 8 horas de inactividad. Necesita usar un pool de conexiones que trate conexiones en espera o use el parámetro "autoReconnect" (consulte "Desarrollo de aplicaciones con MySQL Connector/J").

Además, debe cachear SQLExceptions en su aplicación y tratarlas, en lugar de propagarlas hasta que acaba la aplicación, esto es sólo una buena práctica de programación. MySQL Connector/J actualiza el SQLState (cosulte java.sql.SQLException.getSQLState() en sus APIDOCS) a "08S01" cuando encuentra problemas de conectividad de red durante el procesamiento de una consulta. Su código de aplicación debe tratar de reconectar a MySQL en este punto.

El siguiente ejemplo (simple) muestra cómo debería ser el código que trata estas excepciones:

Ejemplo 25.13. Ejemplo de transacción con lógica de reintento

public void doBusinessOp() throws SQLException {
        Connection conn = null;
        Statement stmt = null;
        ResultSet rs = null;

        //
        // How many times do you want to retry the transaction
        // (or at least _getting_ a connection)?
        //
        int retryCount = 5;

        boolean transactionCompleted = false;

        do {
            try {
                conn = getConnection(); // assume getting this from a
                                        // javax.sql.DataSource, or the
                                        // java.sql.DriverManager

                conn.setAutoCommit(false);

                //
                // Okay, at this point, the 'retry-ability' of the
                // transaction really depends on your application logic,
                // whether or not you're using autocommit (in this case
                // not), and whether you're using transacational storage
                // engines
                //
                // For this example, we'll assume that it's _not_ safe
                // to retry the entire transaction, so we set retry count
                // to 0 at this point
                //
                // If you were using exclusively transaction-safe tables,
                // or your application could recover from a connection going
                // bad in the middle of an operation, then you would not
                // touch 'retryCount' here, and just let the loop repeat
                // until retryCount == 0.
                //
                retryCount = 0;

                stmt = conn.createStatement();

                String query = "SELECT foo FROM bar ORDER BY baz";

                rs = stmt.executeQuery(query);

                while (rs.next()) {
                }

                rs.close();
                rs = null;

                stmt.close();
                stmt = null;

                conn.commit();
                conn.close();
                conn = null;

                transactionCompleted = true;
            } catch (SQLException sqlEx) {

                //
                // The two SQL states that are 'retry-able' are 08S01
                // for a communications error, and 41000 for deadlock.
                //
                // Only retry if the error was due to a stale connection,
                // communications problem or deadlock
                //

                String sqlState = sqlEx.getSQLState();

                if ("08S01".equals(sqlState) || "41000".equals(sqlState)) {
                    retryCount--;
                } else {
                    retryCount = 0;
                }
            } finally {
                if (rs != null) {
                    try {
                        rs.close();
                    } catch (SQLException sqlEx) {
                        // You'd probably want to log this . . .
                    }
                }

                if (stmt != null) {
                    try {
                        stmt.close();
                    } catch (SQLException sqlEx) {
                        // You'd probably want to log this as well . . .
                    }
                }

                if (conn != null) {
                    try {
                        //
                        // If we got here, and conn is not null, the
                        // transaction should be rolled back, as not
                        // all work has been done

                        try {
                            conn.rollback();
                        } finally {
                            conn.close();
                        }
                    } catch (SQLException sqlEx) {
                        //
                        // If we got an exception here, something
                        // pretty serious is going on, so we better
                        // pass it up the stack, rather than just
                        // logging it. . .

                        throw sqlEx;
                    }
                }
            }
        } while (!transactionCompleted && (retryCount > 0));
    }

26.3.5.1.5:

Question:

Intento usar conjuntos de resultados actualizables de JDBC-2.0, y obtengo una excepción diciendo que mi conjunto de resultados no es actualizable.

Answer:

Debido a que MySQL no tiene identificadores de registros, MySQL Connector/J sólo puede actualizar conjuntos de resultados que vengan de consultas en tablas que tengan como mínimo una clave primaria, la consulta debe seleccionar todos los campos de la clave(s) primaria y la consulta sólo puede consultar una tabla (no joins). Esto se explica en la especificación JDBC.

25.3.5.2. Cómo reportar bugs o problemas

El sitio normal en el que reportar bugs es http://bugs.mysql.com/, que es la dirección de nuestra base de datos de bugs. Esta base de datos es pública, y puede ser consultada por cualquiera. Si se loguea en el sistema, debe ser capaz de introducir nuevos reportes.

Si encuentra un error de seguridad sensible en MySSQL, puede enviar un correo a [email protected].

Escribir un buen reporte de bug necesita de paciencia, pero hacerlo bien la primera vez nos ahorra tiempo tanto a nosotros como a usted. Un buen reporte de bug, conteniendo un test de casos completo para el bug, hace que sea muy probable que arreglemos el bug en la siguiente versión.

Esta sección le ayuda a escribir un reporte correctamente para que no pierda tiempo haciendo cosas que no nos ayudan.

Si tiene un reporte de un bug repetible, por favor repórtelo a la base de datos de bugs en http://bugs.mysql.com/.

Cualquier bug que seamos capaces de repetir tiene una alta probabilidad que lo arreglemos en la siguiente versión de MySQL.

Para reportar otros problemas, puede usar una de las listas de correo de MySQL.

Recuerde que es posible para nosotros responder un mensaje que contenga demasiada información, pero no a uno que no contenga suficiente. La gente normalmente omite hechos porque piensan que saben la causa del problema y asumen que algunos detalles no importan.

Un buen principio es el siguiente: si duda acerca de reportar algo, repórtelo. Es más rápido y menso problemático escribir un par de líneas extra en su reporte que esperar la respuesta si debemos pedir que proporcione información no presente en el reporte inicial.

Los errores más comunes en los reportes de bugs son (a) no incluir el número de versión de Connector/J o MySQL usados, y (b) no describir completamente la plataforma donde el Connector/J está instalado (incluyendo la versión de la JVM , y el tipo de plataforma y versión de donde el propio MySQL está instalado).

Esta es información altamente relevante, y en el 99% de los casos el reporte de bug no es útil sin ella. Muy a menudo obtenemos preguntas como "¿Porqué no me funciona a mi?" luego encontramos que la característica pedida no estaba implementada en esa versión de MySQL, o que el bug descrito en el reporte se ha arreglado en versiones posteriores de MySQL.

A veces el error depende de la plataforma; en tales casos, es casi imposible para nosotros arreglar nada sin saber el sistema operativo y el número de versión de la platagorma.

Si es posible, debe crear un caso de uso repetible que no incluya clases de terceras partes.

Para facilitar este proceso, proporcionamos una clase base para tests de uso con Connector/J, llamado ' '. Para crear un caso de uso para Connector/J usando esta clase, cree su propia clase que herede de y sobreescriba los métodos , y ().

En el método , cree código que cree sus tablas y añada los datos necesarios para demostrar el bug.

En el método () , cree código que demuestre el bug usando la tablas y datos creados en el método 'setUp' .

En el método , borre cualquier tabla creada en el método .

En cualquiera de los tres métodos anteriores, debe usar una de las variantes del método () para crear una conexión JDBC para MySQL:

  • getConnection() - Proporciona una conexión para la JDBC URL especificada en getUrl(). Si una conexión ya existe, esa conexión se retorna, de otro modo se crea una nueva conexión.

  • getNewConnection() - Use esto si necesita obtener una nueva conexión para su reporte de bug(p.e. hay más de una conexión involucrada).

  • getConnection(String url) - Retorna una conexión usando una URL dada.

  • getConnection(String url, Properties props) - Retorna una conexión usando la URL y propiedades dadas.

Si necesita usar una URL JDBC diferente a 'jdbc:mysql:///test', sobreescriba también el método .

Use los métodos y para crear condiciones que deben existir en su demostración de casos de uso para el comportamiento que espera ( el comportamiento que observa, que es por lo que está rellenando un reporte de bug).

Finalmente, cree un método () que cree una nueva instancia en su caso de uso, y llame al método :

public static void main(String[] args) throws Exception {
      new MyBugReport().run();
 }

Cuando haya acabado su caso de uso, y haya verificado que demuestra el bug que está reportando, súbalo con su reporte de bug a http://bugs.mysql.com/.

25.3.6. Changelog

# Changelog
# $Id: CHANGES,v 1.38.4.206 2005/05/12 15:25:54 mmatthews Exp $

05-17-05 - Version 3.2.1-alpha

    - Autoreconnect functionality (i.e. autoReconnect=true) is now deprecated.
      An exception will be thrown if you try and use it, use 
      'enableDeprecatedAutoreconnect=true' to still use autoReconnect. However
      this feature will be removed in Connector/J 3.3, see the manual for 
      solutions that don't require autoReconnect to be used.

    - Driver now checks if server variable 'init_connect' is set, and if so
      checks autocommit setting, and applies it.
  
    - If connected to server > 5.0.x, and Statement.setFetchSize( > 0), the
      driver will try and use server prepared statements and fetch
      statements using result set 'cursors'.
  
    - ServerPreparedStatements now correctly 'stream' BLOB/CLOB data to the
      server. You can configure the threshold chunk size using the
      JDBC URL property 'blobSendChunkSize' (the default is one megabyte).
  
    - Support sql mode NO_BACKSLASH_ESCAPES with non-server-side prepared
      statements.

12-23-04 - Version 3.2.0-alpha

    - Fixed incorrect return values from DatabaseMetaData.supportsCatalogIn*().
    
    - Support for 'cursor' based result sets when using ServerPreparedStatements
      and MySQL 5.0 or newer. Result set needs to be forward-only, and a non-zero
      fetch size for this feature to be enabled.
      
    - Refactoring of where logic for prepared statement, server-prepared 
      statement lives.

10-07-05 - Version 3.1.11-stable

    - Fixed BUG#11629 - Spurious "!" on console when character
      encoding is "utf8".
      
    - Fixed statements generated for testcases missing ";" for
      "plain" statements.
      
    - Fixed BUG#11663 - Incorrect generation of testcase scripts 
      for server-side prepared statements.
      
    - Fixed regression caused by fix for BUG#11552 that caused driver
      to return incorrect values for unsigned integers when those 
      integers where within the range of the positive signed type.
    
    - Moved source code to svn repo.
    
    - Fixed BUG#11797 - Escape tokenizer doesn't respect stacked single quotes
      for escapes.
  
    - GEOMETRY type not recognized when using server-side prepared statements.
    
    - Fixed BUG#11879 -- ReplicationConnection won't switch to slave, throws 
      "Catalog can't be null" exception.
      
    - Fixed BUG#12218, properties shared between master and slave with 
      replication connection.
      
    - Fixed BUG#10630, Statement.getWarnings() fails with NPE if statement 
      has been closed.
      
    - Only get char[] from SQL in PreparedStatement.ParseInfo() when needed.
    
    - Fixed BUG#12104 - Geometry types not handled with server-side prepared 
      statements.
      
    - Fixed BUG#11614 - StringUtils.getBytes() doesn't work when using 
      multibyte character encodings and a length in  _characters_ is 
      specified.
      
    - Fixed BUG#11798 - Pstmt.setObject(...., Types.BOOLEAN) throws exception.
    
    - Fixed BUG#11976 - maxPerformance.properties mis-spells 
      "elideSetAutoCommits".
  
    - Fixed BUG#11575 -- DBMD.storesLower/Mixed/UpperIdentifiers()
      reports incorrect values for servers deployed on Windows.
  
    - Fixed BUG#11190 - ResultSet.moveToCurrentRow() fails to work when 
      preceeded by a call to ResultSet.moveToInsertRow().
  
    - Fixed BUG#11115, VARBINARY data corrupted when using server-side
      prepared statements and .setBytes().

    - Fixed BUG#12229 - explainSlowQueries hangs with server-side
      prepared statements.
  
    - Fixed BUG#11498 - Escape processor didn't honor strings demarcated
      with double quotes.
  
    - Lifted restriction of changing streaming parameters with server-side
      prepared statements. As long as _all_ streaming parameters were set
      before execution, .clearParameters() does not have to be called. 
      (due to limitation of client/server protocol, prepared statements
       can not reset _individual_ stream data on the server side).
   
    - Reworked Field class, *Buffer, and MysqlIO to be aware of field
      lengths > Integer.MAX_VALUE.
  
    - Updated DBMD.supportsCorrelatedQueries() to return true for versions > 
      4.1, supportsGroupByUnrelated() to return true and 
      getResultSetHoldability() to return HOLD_CURSORS_OVER_COMMIT.
  
    - Fixed BUG#12541 - Handling of catalog argument in 
      DatabaseMetaData.getIndexInfo(), which also means changes to the following
      methods in DatabaseMetaData:
  
    - getBestRowIdentifier()
    - getColumns()
    - getCrossReference()
    - getExportedKeys()
    - getImportedKeys()
    - getIndexInfo()
    - getPrimaryKeys()
    - getProcedures() (and thus indirectly getProcedureColumns())
    - getTables()
  
      The "catalog" argument in all of these methods now behaves in the following
      way:
  
        - Specifying NULL means that catalog will not be used to filter the
          results (thus all databases will be searched), unless you've
          set "nullCatalogMeansCurrent=true" in your JDBC URL properties.
      
        - Specifying "" means "current" catalog, even though this isn't quite
          JDBC spec compliant, it's there for legacy users.
      
        - Specifying a catalog works as stated in the API docs.
    
        - Made Connection.clientPrepare() available from "wrapped" connections
          in the jdbc2.optional package (connections built by 
          ConnectionPoolDataSource instances).
      
    - Added Connection.isMasterConnection() for clients to be able to determine
      if a multi-host master/slave connection is connected to the first host
      in the list.
      
    - Fixed BUG#12753 - Tokenizer for "=" in URL properties was causing
      sessionVariables=.... to be parameterized incorrectly.

    - Fixed BUG#11781, foreign key information that is quoted is 
      parsed incorrectly when DatabaseMetaData methods use that
      information.
      
    - The "sendBlobChunkSize" property is now clamped to "max_allowed_packet"
      with consideration of stream buffer size and packet headers to avoid
      PacketTooBigExceptions when "max_allowed_packet" is similar in size
      to the default "sendBlobChunkSize" which is 1M.
      
    - CallableStatement.clearParameters() now clears resources associated
      with INOUT/OUTPUT parameters as well as INPUT parameters.
      
    - Fixed BUG#12417 - Connection.prepareCall() is database name 
      case-sensitive (on Windows systems).
      
    - Fixed BUG#12752 - Cp1251 incorrectly mapped to win1251 for 
      servers newer than 4.0.x.
      
    - Fixed BUG#12970 - java.sql.Types.OTHER returned for 
      BINARY and VARBINARY columns when using 
      DatabaseMetaData.getColumns(). 
  
    - ServerPreparedStatement.getBinding() now checks if the statement
      is closed before attempting to reference the list of parameter
      bindings, to avoid throwing a NullPointerException.
      
    - Fixed BUG#13277 - ResultSetMetaData from 
      Statement.getGeneratedKeys() caused NullPointerExceptions to be
      thrown whenever a method that required a connection reference
      was called.
      
    - Backport of Field class, ResultSetMetaData.getColumnClassName(),
      and ResultSet.getObject(int) changes from 5.0 branch to fix
      behavior surrounding VARCHAR BINARY/VARBINARY and related
      types.
      
    - Fixed NullPointerException when converting "catalog" parameter
      in many DatabaseMetaDataMethods to byte[]s (for the result set)
      when the parameter is null. ("null" isn't technically allowed
      by the JDBC specification, but we've historically allowed it).
      
    - Backport of VAR[BINARY|CHAR] [BINARY] types detection from 
      5.0 branch.
    
    - Read response in MysqlIO.sendFileToServer(), even if the 
      local file can't be opened, otherwise next query issued
      will fail, because it's reading the response to the empty
      LOAD DATA INFILE packet sent to the server.
      
    - Workaround for BUG#13374 - ResultSet.getStatement() 
      on closed result set returns NULL (as per JDBC 4.0 spec,
      but not backwards-compatible). Set the connection property
      "retainStatementAfterResultSetClose" to "true" to be able
      to retrieve a ResultSet's statement after the ResultSet has
      been closed via .getStatement() (the default is "false", to
      be JDBC-compliant and to reduce the chance that code using
      JDBC leaks Statement instances).
      
    - Fixed BUG#13453 - URL configuration parameters don't allow
      '&' or '=' in their values. The JDBC driver now parses 
      configuration parameters as if they are encoded using the 
      application/x-www-form-urlencoded format as specified
      by java.net.URLDecoder - 
      http://java.sun.com/j2se/1.5.0/docs/api/java/net/URLDecoder.html
      
      If the '%' character is present in a configuration property,
      it must now be represented as %25, which is the encoded form
      of '%' when using application/x-www-form-urlencoded encoding.
      
    - The configuration property "sessionVariables" now allows you to
      specify variables that start with the "@" sign.
      
    - Fixed BUG#13043 - when 'gatherPerfMetrics' is enabled for 
      servers older than 4.1.0, a NullPointerException is thrown from 
      the constructor of ResultSet if the query doesn't use any tables.

06-23-05 - Version 3.1.10-stable

    - Fixed connecting without a database specified raised an exception
      in MysqlIO.changeDatabaseTo().
  
    - Initial implemention of ParameterMetadata for 
      PreparedStatement.getParameterMetadata(). Only works fully
      for CallableStatements, as current server-side prepared statements
      return every parameter as a VARCHAR type.
    
06-22-05 - Version 3.1.9-stable

    - Overhaul of character set configuration, everything now
      lives in a properties file.
  
    - Driver now correctly uses CP932 if available on the server
      for Windows-31J, CP932 and MS932 java encoding names, 
      otherwise it resorts to SJIS, which is only a close 
      approximation. Currently only MySQL-5.0.3 and newer (and
      MySQL-4.1.12 or .13, depending on when the character set
      gets backported) can reliably support any variant of CP932.

    - Fixed BUG#9064 - com.mysql.jdbc.PreparedStatement.ParseInfo 
      does unnecessary call to toCharArray().

    - Fixed Bug#10144 - Memory leak in ServerPreparedStatement if 
      serverPrepare() fails.
 
    - Actually write manifest file to correct place so it ends up
      in the binary jar file.

    - Added "createDatabaseIfNotExist" property (default is "false"),
      which will cause the driver to ask the server to create the 
      database specified in the URL if it doesn't exist. You must have
      the appropriate privileges for database creation for this to
      work.

    - Fixed BUG#10156 - Unsigned SMALLINT treated as signed for ResultSet.getInt(),
      fixed all cases for UNSIGNED integer values and server-side prepared statements,
      as well as ResultSet.getObject() for UNSIGNED TINYINT.
 
    - Fixed BUG#10155, double quotes not recognized when parsing 
      client-side prepared statements.
  
    - Made enableStreamingResults() visible on 
      com.mysql.jdbc.jdbc2.optional.StatementWrapper.
  
    - Made ServerPreparedStatement.asSql() work correctly so auto-explain
      functionality would work with server-side prepared statements.
  
    - Made JDBC2-compliant wrappers public in order to allow access to
      vendor extensions.
  
    - Cleaned up logging of profiler events, moved code to dump a profiler
      event as a string to com.mysql.jdbc.log.LogUtils so that third
      parties can use it.
  
    - DatabaseMetaData.supportsMultipleOpenResults() now returns true. The
      driver has supported this for some time, DBMD just missed that fact.
  
    - Fixed BUG#10310 - Driver doesn't support {?=CALL(...)} for calling
      stored functions. This involved adding support for function retrieval
      to DatabaseMetaData.getProcedures() and getProcedureColumns() as well.
      
    - Fixed BUG#10485, SQLException thrown when retrieving YEAR(2) 
      with ResultSet.getString(). The driver will now always treat YEAR types
      as java.sql.Dates and return the correct values for getString(). 
      Alternatively, the "yearIsDateType" connection property can be set to
      "false" and the values will be treated as SHORTs.
  
    - The datatype returned for TINYINT(1) columns when "tinyInt1isBit=true" 
      (the default) can be switched between Types.BOOLEAN and Types.BIT
      using the new configuration property "transformedBitIsBoolean", which
      defaults to "false". If set to "false" (the default), 
      DatabaseMetaData.getColumns() and ResultSetMetaData.getColumnType() 
      will return Types.BOOLEAN for TINYINT(1) columns. If "true", 
      Types.BOOLEAN will be returned instead. Irregardless of this configuration
      property, if "tinyInt1isBit" is enabled, columns with the type TINYINT(1)
      will be returned as java.lang.Boolean instances from 
      ResultSet.getObject(..), and ResultSetMetaData.getColumnClassName()
      will return "java.lang.Boolean".

    - Fixed BUG#10496 - SQLException is thrown when using property 
      "characterSetResults" with cp932 or eucjpms.
      
    - Reorganized directory layout, sources now in "src" folder,
      don't pollute parent directory when building, now output goes
      to "./build", distribution goes to "./dist".
      
    - Added support/bug hunting feature that generates .sql test
      scripts to STDERR when "autoGenerateTestcaseScript" is set
      to "true".
      
    - Fixed BUG#10850 - 0-length streams not sent to server when
      using server-side prepared statements.
    
    - Setting "cachePrepStmts=true" now causes the Connection to also 
      cache the check the driver performs to determine if a prepared 
      statement can be server-side or not, as well as caches server-side
      prepared statements for the lifetime of a connection. As before,
      the "prepStmtCacheSize" parameter controls the size of these
      caches.
      
    - Try to handle OutOfMemoryErrors more gracefully. Although not
      much can be done, they will in most cases close the connection
      they happened on so that further operations don't run into 
      a connection in some unknown state. When an OOM has happened, 
      any further operations on the connection will fail with a 
      "Connection closed" exception that will also list the OOM exception
      as the reason for the implicit connection close event.
      
    - Don't send COM_RESET_STMT for each execution of a server-side
      prepared statement if it isn't required.
      
    - Driver detects if you're running MySQL-5.0.7 or later, and does
      not scan for "LIMIT ?[,?]" in statements being prepared, as the
      server supports those types of queries now.
      
    - Fixed BUG#11115, Varbinary data corrupted when using server-side
      prepared statements and ResultSet.getBytes().
      
    - Connection.setCatalog() is now aware of the "useLocalSessionState"
      configuration property, which when set to true will prevent
      the driver from sending "USE ..." to the server if the requested
      catalog is the same as the current catalog.
      
    - Added the following configuration bundles, use one or many via
      the "useConfigs" configuration property:
    
        * maxPerformance -- maximum performance without being reckless
        * solarisMaxPerformance -- maximum performance for Solaris,
                                   avoids syscalls where it can
        * 3-0-Compat -- Compatibility with Connector/J 3.0.x functionality
        
    - Added "maintainTimeStats" configuration property (defaults to "true"),
      which tells the driver whether or not to keep track of the last query time
      and the last successful packet sent to the server's time. If set to
      false, removes two syscalls per query.
    
    - Fixed BUG#11259, autoReconnect ping causes exception on connection 
      startup.
      
    - Fixed BUG#11360 Connector/J dumping query into SQLException twice
    
    - Fixed PreparedStatement.setClob() not accepting null as a parameter.
    
    - Fixed BUG#11411 - Production package doesn't include JBoss integration 
      classes.
      
    - Removed nonsensical "costly type conversion" warnings when using 
      usage advisor.


04-14-05 - Version 3.1.8-stable

    - Fixed DatabaseMetaData.getTables() returning views when they were
      not asked for as one of the requested table types.

    - Added support for new precision-math DECIMAL type in MySQL >= 5.0.3.

    - Fixed ResultSet.getTime() on a NULL value for server-side prepared
      statements throws NPE.

    - Made Connection.ping() a public method.

    - Fixed Bug#8868, DATE_FORMAT() queries returned as BLOBs from getObject().

    - ServerPreparedStatements now correctly 'stream' BLOB/CLOB data to the
      server. You can configure the threshold chunk size using the
      JDBC URL property 'blobSendChunkSize' (the default is one megabyte).

    - BlobFromLocator now uses correct identifier quoting when generating
      prepared statements.

    - Server-side session variables can be preset at connection time by
      passing them as a comma-delimited list for the connection property
      'sessionVariables'.

    - Fixed regression in ping() for users using autoReconnect=true.

    - Fixed BUG#9040 - PreparedStatement.addBatch() doesn't work with server-side
      prepared statements and streaming BINARY data.

    - Fixed BUG#8800 - DBMD.supportsMixedCase*Identifiers() returns wrong
      value on servers running on case-sensitive filesystems.

    - Fixed BUG#9206, can not use 'UTF-8' for characterSetResults
      configuration property.

    - Fixed BUG#9236, a continuation of BUG#8868, where functions used in queries
      that should return non-string types when resolved by temporary tables suddenly
      become opaque binary strings (work-around for server limitation). Also fixed
      fields with type of CHAR(n) CHARACTER SET BINARY to return correct/matching
      classes for RSMD.getColumnClassName() and ResultSet.getObject().

    - Fixed BUG#8792 - DBMD.supportsResultSetConcurrency() not returning
      true for forward-only/read-only result sets (we obviously support this).

    - Fixed BUG#8803, 'DATA_TYPE' column from DBMD.getBestRowIdentifier()
      causes ArrayIndexOutOfBoundsException when accessed (and in fact, didn't
      return any value).

    - Check for empty strings ('') when converting char/varchar column data to numbers,
      throw exception if 'emptyStringsConvertToZero' configuration property is set
      to 'false' (for backwards-compatibility with 3.0, it is now set to 'true'
      by default, but will most likely default to 'false' in 3.2).

    - Fixed BUG#9320 - PreparedStatement.getMetaData() inserts blank row in database
      under certain conditions when not using server-side prepared statements.

    - Connection.canHandleAsPreparedStatement() now makes 'best effort' to distinguish
      LIMIT clauses with placeholders in them from ones without in order to have fewer
      false positives when generating work-arounds for statements the server cannot
      currently handle as server-side prepared statements.

    - Fixed build.xml to not compile log4j logging if log4j not available.

    - Added support for the c3p0 connection pool's (http://c3p0.sf.net/)
      validation/connection checker interface which uses the lightweight
      'COM_PING' call to the server if available. To use it, configure your
      c3p0 connection pool's 'connectionTesterClassName' property to use
      'com.mysql.jdbc.integration.c3p0.MysqlConnectionTester'.

    - Better detection of LIMIT inside/outside of quoted strings so that
      the driver can more correctly determine whether a prepared statement
      can be prepared on the server or not.

    - Fixed BUG#9319 - Stored procedures with same name in
      different databases confuse the driver when it tries to determine
      parameter counts/types.

    - Added finalizers to ResultSet and Statement implementations to be JDBC
      spec-compliant, which requires that if not explicitly closed, these
      resources should be closed upon garbage collection.

    - Fixed BUG#9682 - Stored procedures with DECIMAL parameters with
      storage specifications that contained "," in them would fail.

    - PreparedStatement.setObject(int, Object, int type, int scale) now
      uses scale value for BigDecimal instances.

    - Fixed BUG#9704 - Statement.getMoreResults() could throw NPE when
      existing result set was .close()d.

    - The performance metrics feature now gathers information about
      number of tables referenced in a SELECT.

    - The logging system is now automatically configured. If the value has
      been set by the user, via the URL property "logger" or the system
      property "com.mysql.jdbc.logger", then use that, otherwise, autodetect
      it using the following steps:

         Log4j, if it's available,
         Then JDK1.4 logging,
         Then fallback to our STDERR logging.

    - Fixed BUG#9778, DBMD.getTables() shouldn't return tables if views
      are asked for, even if the database version doesn't support views.

    - Fixed driver not returning 'true' for '-1' when ResultSet.getBoolean()
      was called on result sets returned from server-side prepared statements.

    - Added a Manifest.MF file with implementation information to the .jar
      file.

    - More tests in Field.isOpaqueBinary() to distinguish opaque binary (i.e.
      fields with type CHAR(n) and CHARACTER SET BINARY) from output of
      various scalar and aggregate functions that return strings.

    - Fixed BUG#9917 - Should accept null for catalog (meaning use current)
      in DBMD methods, even though it's not JDBC-compliant for legacy's sake.
      Disable by setting connection property "nullCatalogMeansCurrent" to "false"
      (which will be the default value in C/J 3.2.x).

    - Fixed BUG#9769 - Should accept null for name patterns in DBMD (meaning "%"),
      even though it isn't JDBC compliant, for legacy's sake. Disable by setting
      connection property "nullNamePatternMatchesAll" to "false" (which will be
      the default value in C/J 3.2.x).

02-18-05 - Version 3.1.7-stable

    - Fixed BUG#7686, Timestamp key column data needed "_binary'"
      stripped for UpdatableResultSet.refreshRow().

    - Fixed BUG#7715 - Timestamps converted incorrectly to strings
      with Server-side prepared statements and updatable result sets.

    - Detect new sql_mode variable in string form (it used to be
      integer) and adjust quoting method for strings appropriately.

    - Added 'holdResultsOpenOverStatementClose' property (default is
      false), that keeps result sets open over statement.close() or new
      execution on same statement (suggested by Kevin Burton).

    - Fixed BUG#7952 -- Infinite recursion when 'falling back' to master
      in failover configuration.

    - Disable multi-statements (if enabled) for MySQL-4.1 versions prior
      to version 4.1.10 if the query cache is enabled, as the server
      returns wrong results in this configuration.

    - Fixed duplicated code in configureClientCharset() that prevented
      useOldUTF8Behavior=true from working properly.

    - Removed 'dontUnpackBinaryResults' functionality, the driver now
      always stores results from server-side prepared statements as-is
      from the server and unpacks them on demand.

    - Fixed BUG#8096 where emulated locators corrupt binary data
      when using server-side prepared statements.

    - Fixed synchronization issue with
      ServerPreparedStatement.serverPrepare() that could cause
      deadlocks/crashes if connection was shared between threads.

    - By default, the driver now scans SQL you are preparing via all
      variants of Connection.prepareStatement() to determine if it is a
      supported type of statement to prepare on the server side, and if
      it is not supported by the server, it instead prepares it as a
      client-side emulated prepared statement (BUG#4718). You can
      disable this by passing 'emulateUnsupportedPstmts=false' in your
      JDBC URL.

    - Remove _binary introducer from parameters used as in/out
      parameters in CallableStatement.

    - Always return byte[]s for output parameters registered as *BINARY.

    - Send correct value for 'boolean' "true" to server for
      PreparedStatement.setObject(n, "true", Types.BIT).

    - Fixed bug with Connection not caching statements from
      prepareStatement() when the statement wasn't a server-side
      prepared statement.

    - Choose correct 'direction' to apply time adjustments when both
      client and server are in GMT timezone when using
      ResultSet.get(..., cal) and PreparedStatement.set(...., cal).

    - Added 'dontTrackOpenResources' option (default is false, to be
      JDBC compliant), which helps with memory use for non-well-behaved
      apps (i.e applications which don't close Statements when they
      should).

    - Fixed BUG#8428 - ResultSet.getString() doesn't maintain format
      stored on server, bug fix only enabled when 'noDatetimeStringSync'
      property is set to 'true' (the default is 'false').

    - Fixed NPE in ResultSet.realClose() when using usage advisor and
      result set was already closed.

    - Fixed BUG#8487 - PreparedStatements not creating streaming result
      sets.

    - Don't pass NULL to String.valueOf() in
      ResultSet.getNativeConvertToString(), as it stringifies it (i.e.
      returns "null"), which is not correct for the method in question.

    - Fixed BUG#8484 - ResultSet.getBigDecimal() throws exception
      when rounding would need to occur to set scale. The driver now
      chooses a rounding mode of 'half up' if non-rounding
      BigDecimal.setScale() fails.

    - Added 'useLocalSessionState' configuration property, when set to
      'true' the JDBC driver trusts that the application is well-behaved
      and only sets autocommit and transaction isolation levels using
      the methods provided on java.sql.Connection, and therefore can
      manipulate these values in many cases without incurring
      round-trips to the database server.

    - Added enableStreamingResults() to Statement for connection pool
      implementations that check Statement.setFetchSize() for
      specification-compliant values. Call Statement.setFetchSize(>=0)
      to disable the streaming results for that statement.

    - Added support for BIT type in MySQL-5.0.3. The driver will treat
      BIT(1-8) as the JDBC standard BIT type (which maps to
      java.lang.Boolean), as the server does not currently send enough
      information to determine the size of a bitfield when < 9 bits are
      declared. BIT(>9) will be treated as VARBINARY, and will return
      byte[] when getObject() is called.

12-23-04 - Version 3.1.6-stable

    - Fixed hang on SocketInputStream.read() with Statement.setMaxRows() and
      multiple result sets when driver has to truncate result set directly,
      rather than tacking a 'LIMIT n' on the end of it.

    - Fixed BUG#7026 - DBMD.getProcedures() doesn't respect catalog parameter.

12-02-04 - Version 3.1.5-gamma

    - Fix comparisons made between string constants and dynamic strings that
      are either toUpperCase()d or toLowerCase()d to use Locale.ENGLISH, as
      some locales 'override' case rules for English. Also use
      StringUtils.indexOfIgnoreCase() instead of .toUpperCase().indexOf(),
      avoids creating a very short-lived transient String instance.

    - Fixed BUG#5235 - Server-side prepared statements did not honor
      'zeroDateTimeBehavior' property, and would cause class-cast
      exceptions when using ResultSet.getObject(), as the all-zero string
      was always returned.

    - Fixed batched updates with server prepared statements weren't looking if
      the types had changed for a given batched set of parameters compared
      to the previous set, causing the server to return the error
      'Wrong arguments to mysql_stmt_execute()'.

    - Handle case when string representation of timestamp contains trailing '.'
      with no numbers following it.

    - Fixed BUG#5706 - Inefficient detection of pre-existing string instances
      in ResultSet.getNativeString().

    - Don't throw exceptions for Connection.releaseSavepoint().

    - Use a per-session Calendar instance by default when decoding dates
      from ServerPreparedStatements (set to old, less performant behavior by
      setting property 'dynamicCalendars=true').

    - Added experimental configuration property 'dontUnpackBinaryResults',
      which delays unpacking binary result set values until they're asked for,
      and only creates object instances for non-numerical values (it is set
      to 'false' by default). For some usecase/jvm combinations, this is
      friendlier on the garbage collector.

    - Fixed BUG#5729 - UNSIGNED BIGINT unpacked incorrectly from
      server-side prepared statement result sets.

    - Fixed BUG#6225 - ServerSidePreparedStatement allocating short-lived
      objects un-necessarily.

    - Removed un-wanted new Throwable() in ResultSet constructor due to bad
      merge (caused a new object instance that was never used for every result
      set created) - Found while profiling for BUG#6359.

    - Fixed too-early creation of StringBuffer in EscapeProcessor.escapeSQL(),
      also return String when escaping not needed (to avoid unnecssary object
      allocations). Found while profiling for BUG#6359.

    - Use null-safe-equals for key comparisons in updatable result sets.

    - Fixed BUG#6537, SUM() on Decimal with server-side prepared statement ignores
      scale if zero-padding is needed (this ends up being due to conversion to DOUBLE
      by server, which when converted to a string to parse into BigDecimal, loses all
      'padding' zeros).

    - Use DatabaseMetaData.getIdentifierQuoteString() when building DBMD
      queries.

    - Use 1MB packet for sending file for LOAD DATA LOCAL INFILE if that
      is < 'max_allowed_packet' on server.

    - Fixed BUG#6399, ResultSetMetaData.getColumnDisplaySize() returns incorrect
      values for multi-byte charsets.

    - Make auto-deserialization of java.lang.Objects stored in BLOBs
      configurable via 'autoDeserialize' property (defaults to 'false').

    - Re-work Field.isOpaqueBinary() to detect 'CHAR(n) CHARACTER SET BINARY'
      to support fixed-length binary fields for ResultSet.getObject().

    - Use our own implementation of buffered input streams to get around
      blocking behavior of java.io.BufferedInputStream. Disable this with
      'useReadAheadInput=false'.

    - Fixed BUG#6348, failing to connect to the server when one of the
      addresses for the given host name is IPV6 (which the server does
      not yet bind on). The driver now loops through _all_ IP addresses
      for a given host, and stops on the first one that accepts() a
      socket.connect().

09-04-04 - Version 3.1.4-beta

    - Fixed BUG#4510 - connector/j 3.1.3 beta does not handle integers
      correctly (caused by changes to support unsigned reads in
      Buffer.readInt() -> Buffer.readShort()).

    - Added support in DatabaseMetaData.getTables() and getTableTypes()
      for VIEWs which are now available in MySQL server version 5.0.x.

    - Fixed BUG#4642 -- ServerPreparedStatement.execute*() sometimes
      threw ArrayIndexOutOfBoundsException when unpacking field metadata.

    - Optimized integer number parsing, enable 'old' slower integer parsing
      using JDK classes via 'useFastIntParsing=false' property.

    - Added 'useOnlyServerErrorMessages' property, which causes message text
      in exceptions generated by the server to only contain the text sent by
      the server (as opposed to the SQLState's 'standard' description, followed
      by the server's error message). This property is set to 'true' by default.

    - Fixed BUG#4689 - ResultSet.wasNull() does not work for primatives if a
      previous null was returned.

    - Track packet sequence numbers if enablePacketDebug=true, and throw an
      exception if packets received out-of-order.

    - Fixed BUG#4482, ResultSet.getObject() returns wrong type for strings
      when using prepared statements.

    - Calling MysqlPooledConnection.close() twice (even though an application
      error), caused NPE. Fixed.

    - Fixed BUG#5012 -- ServerPreparedStatements dealing with return of
      DECIMAL type don't work.

    - Fixed BUG#5032 -- ResultSet.getObject() doesn't return
      type Boolean for pseudo-bit types from prepared statements on 4.1.x
      (shortcut for avoiding extra type conversion when using binary-encoded
      result sets obscurred test in getObject() for 'pseudo' bit type)

    - You can now use URLs in 'LOAD DATA LOCAL INFILE' statements, and the
      driver will use Java's built-in handlers for retreiving the data and
      sending it to the server. This feature is not enabled by default,
      you must set the 'allowUrlInLocalInfile' connection property to 'true'.

    - The driver is more strict about truncation of numerics on
      ResultSet.get*(), and will throw a SQLException when truncation is
      detected. You can disable this by setting 'jdbcCompliantTruncation' to
      false (it is enabled by default, as this functionality is required
      for JDBC compliance).

    - Added three ways to deal with all-zero datetimes when reading them from
      a ResultSet, 'exception' (the default), which throws a SQLException
      with a SQLState of 'S1009', 'convertToNull', which returns NULL instead of
      the date, and 'round', which rounds the date to the nearest closest value
      which is '0001-01-01'.

    - Fixed ServerPreparedStatement to read prepared statement metadata off
      the wire, even though it's currently a placeholder instead of using
      MysqlIO.clearInputStream() which didn't work at various times because
      data wasn't available to read from the server yet. This fixes sporadic
      errors users were having with ServerPreparedStatements throwing
      ArrayIndexOutOfBoundExceptions.

    - Use com.mysql.jdbc.Message's classloader when loading resource bundle,
      should fix sporadic issues when the caller's classloader can't locate
      the resource bundle.

07-07-04 - Version 3.1.3-beta

    - Mangle output parameter names for CallableStatements so they
      will not clash with user variable names.

    - Added support for INOUT parameters in CallableStatements.

    - Fix for BUG#4119, null bitmask sent for server-side prepared
      statements was incorrect.

    - Use SQL Standard SQL states by default, unless 'useSqlStateCodes'
      property is set to 'false'.

    - Added packet debuging code (see the 'enablePacketDebug' property
      documentation).

    - Added constants for MySQL error numbers (publicly-accessible,
      see com.mysql.jdbc.MysqlErrorNumbers), and the ability to
      generate the mappings of vendor error codes to SQLStates
      that the driver uses (for documentation purposes).

    - Externalized more messages (on-going effort).

    - Fix for BUG#4311 - Error in retrieval of mediumint column with
      prepared statements and binary protocol.

    - Support new timezone variables in MySQL-4.1.3 when
      'useTimezone=true'

    - Support for unsigned numerics as return types from prepared statements.
      This also causes a change in ResultSet.getObject() for the 'bigint unsigned'
      type, which used to return BigDecimal instances, it now returns instances
      of java.lang.BigInteger.

06-09-04 - Version 3.1.2-alpha

    - Fixed stored procedure parameter parsing info when size was
      specified for a parameter (i.e. char(), varchar()).

    - Enabled callable statement caching via 'cacheCallableStmts'
      property.

    - Fixed case when no output parameters specified for a
      stored procedure caused a bogus query to be issued
      to retrieve out parameters, leading to a syntax error
      from the server.

    - Fixed case when no parameters could cause a NullPointerException
      in CallableStatement.setOutputParameters().

    - Removed wrapping of exceptions in MysqlIO.changeUser().

    - Fixed sending of split packets for large queries, enabled nio
      ability to send large packets as well.

    - Added .toString() functionality to ServerPreparedStatement,
      which should help if you're trying to debug a query that is
      a prepared statement (it shows SQL as the server would process).

    - Added 'gatherPerformanceMetrics' property, along with properties
      to control when/where this info gets logged (see docs for more
      info).

    - ServerPreparedStatements weren't actually de-allocating
      server-side resources when .close() was called.

    - Added 'logSlowQueries' property, along with property
      'slowQueriesThresholdMillis' to control when a query should
      be considered 'slow'.

    - Correctly map output parameters to position given in
      prepareCall() vs. order implied during registerOutParameter() -
      fixes BUG#3146.

    - Correctly detect initial character set for servers >= 4.1.0

    - Cleaned up detection of server properties.

    - Support placeholder for parameter metadata for server >= 4.1.2

    - Fix for BUG#3539 getProcedures() does not return any procedures in
      result set

    - Fix for BUG#3540 getProcedureColumns() doesn't work with wildcards
      for procedure name

    - Fixed BUG#3520 -- DBMD.getSQLStateType() returns incorrect value.

    - Added 'connectionCollation' property to cause driver to issue
      'set collation_connection=...' query on connection init if default
      collation for given charset is not appropriate.

    - Fixed DatabaseMetaData.getProcedures() when run on MySQL-5.0.0 (output of
    'show procedure status' changed between 5.0.1 and 5.0.0.

    - Fixed BUG#3804 -- getWarnings() returns SQLWarning instead of DataTruncation

    - Don't enable server-side prepared statements for server version 5.0.0 or 5.0.1,
    as they aren't compatible with the '4.1.2+' style that the driver uses (the driver
    expects information to come back that isn't there, so it hangs).

02-14-04 - Version 3.1.1-alpha

    - Fixed bug with UpdatableResultSets not using client-side
    prepared statements.

    - Fixed character encoding issues when converting bytes to
      ASCII when MySQL doesn't provide the character set, and
      the JVM is set to a multi-byte encoding (usually affecting
      retrieval of numeric values).

    - Unpack 'unknown' data types from server prepared statements
      as Strings.

    - Implemented long data (Blobs, Clobs, InputStreams, Readers)
      for server prepared statements.

    - Implemented Statement.getWarnings() for MySQL-4.1 and newer
      (using 'SHOW WARNINGS').

    - Default result set type changed to TYPE_FORWARD_ONLY
      (JDBC compliance).

    - Centralized setting of result set type and concurrency.

    - Re-factored how connection properties are set and exposed
      as DriverPropertyInfo as well as Connection and DataSource
      properties.

    - Support for NIO. Use 'useNIO=true' on platforms that support
      NIO.

    - Support for SAVEPOINTs (MySQL >= 4.0.14 or 4.1.1).

    - Support for mysql_change_user()...See the changeUser() method
      in com.mysql.jdbc.Connection.

    - Reduced number of methods called in average query to be more
      efficient.

    - Prepared Statements will be re-prepared on auto-reconnect. Any errors
      encountered are postponed until first attempt to re-execute the
      re-prepared statement.

    - Ensure that warnings are cleared before executing queries
      on prepared statements, as-per JDBC spec (now that we support
      warnings).

    - Support 'old' profileSql capitalization in ConnectionProperties.
      This property is deprecated, you should use 'profileSQL' if possible.

    - Optimized Buffer.readLenByteArray() to return shared empty byte array
      when length is 0.

    - Allow contents of PreparedStatement.setBlob() to be retained
      between calls to .execute*().

    - Deal with 0-length tokens in EscapeProcessor (caused by callable
      statement escape syntax).

    - Check for closed connection on delete/update/insert row operations in
      UpdatableResultSet.

    - Fix support for table aliases when checking for all primary keys in
      UpdatableResultSet.

    - Removed useFastDates connection property.

    - Correctly initialize datasource properties from JNDI Refs, including
      explicitly specified URLs.

    - DatabaseMetaData now reports supportsStoredProcedures() for
      MySQL versions >= 5.0.0

    - Fixed stack overflow in Connection.prepareCall() (bad merge).

    - Fixed IllegalAccessError to Calendar.getTimeInMillis() in DateTimeValue
      (for JDK < 1.4).

    - Fix for BUG#1673, where DatabaseMetaData.getColumns() is not
      returning correct column ordinal info for non '%' column name patterns.

    - Merged fix of datatype mapping from MySQL type 'FLOAT' to
      java.sql.Types.REAL from 3.0 branch.

    - Detect collation of column for RSMD.isCaseSensitive().

    - Fixed sending of queries > 16M.

    - Added named and indexed input/output parameter support to CallableStatement.
      MySQL-5.0.x or newer.

    - Fixed NullPointerException in ServerPreparedStatement.setTimestamp(),
      as well as year and month descrepencies in
      ServerPreparedStatement.setTimestamp(), setDate().

    - Added ability to have multiple database/JVM targets for compliance
      and regression/unit tests in build.xml.

    - Fixed NPE and year/month bad conversions when accessing some
      datetime functionality in ServerPreparedStatements and their
      resultant result sets.

    - Display where/why a connection was implicitly closed (to
      aid debugging).

    - CommunicationsException implemented, that tries to determine
      why communications was lost with a server, and displays
      possible reasons when .getMessage() is called.

    - Fixed BUG#2359, NULL values for numeric types in binary
      encoded result sets causing NullPointerExceptions.

    - Implemented Connection.prepareCall(), and DatabaseMetaData.
      getProcedures() and getProcedureColumns().

    - Reset 'long binary' parameters in ServerPreparedStatement when
      clearParameters() is called, by sending COM_RESET_STMT to the
      server.

    - Merged prepared statement caching, and .getMetaData() support
      from 3.0 branch.

    - Fixed off-by-1900 error in some cases for
      years in TimeUtil.fastDate/TimeCreate() when unpacking results
      from server-side prepared statements.

    - Fixed BUG#2502 -- charset conversion issue in getTables().

    - Implemented multiple result sets returned from a statement
      or stored procedure.

    - Fixed BUG#2606 -- Server side prepared statements not returning
      datatype 'YEAR' correctly.

    - Enabled streaming of result sets from server-side prepared
      statements.

    - Fixed BUG#2623 -- Class-cast exception when using
      scrolling result sets and server-side prepared statements.

    - Merged unbuffered input code from 3.0.

    - Fixed ConnectionProperties that weren't properly exposed
      via accessors, cleaned up ConnectionProperties code.

    - Fixed BUG#2671, NULL fields not being encoded correctly in
      all cases in server side prepared statements.

    - Fixed rare buffer underflow when writing numbers into buffers
      for sending prepared statement execution requests.

    - Use DocBook version of docs for shipped versions of drivers.

02-18-03 - Version 3.1.0-alpha

    - Added 'requireSSL' property.

    - Added 'useServerPrepStmts' property (default 'false'). The
      driver will use server-side prepared statements when the
      server version supports them (4.1 and newer) when this
      property is set to 'true'. It is currently set to 'false'
      by default until all bind/fetch functionality has been
      implemented. Currently only DML prepared statements are
      implemented for 4.1 server-side prepared statements.

    - Track open Statements, close all when Connection.close()
      is called (JDBC compliance).

06-23-05 - Version 3.0.17-ga

    - Fixed BUG#5874, Timestamp/Time conversion goes in the wrong 'direction'
      when useTimeZone='true' and server timezone differs from client timezone.

    - Fixed BUG#7081, DatabaseMetaData.getIndexInfo() ignoring 'unique'
      parameter.

    - Support new protocol type 'MYSQL_TYPE_VARCHAR'.

    - Added 'useOldUTF8Behavoior' configuration property, which causes
      JDBC driver to act like it did with MySQL-4.0.x and earlier when
      the character encoding is 'utf-8' when connected to MySQL-4.1 or
      newer.

    - Fixed BUG#7316 - Statements created from a pooled connection were
      returning physical connection instead of logical connection when
      getConnection() was called.

    - Fixed BUG#7033 - PreparedStatements don't encode Big5 (and other
      multi-byte) character sets correctly in static SQL strings.

    - Fixed BUG#6966, connections starting up failed-over (due to down master)
      never retry master.

    - Fixed BUG#7061, PreparedStatement.fixDecimalExponent() adding extra
      '+', making number unparseable by MySQL server.

    - Fixed BUG#7686, Timestamp key column data needed "_binary'" stripped for
      UpdatableResultSet.refreshRow().

    - Backported SQLState codes mapping from Connector/J 3.1, enable with
      'useSqlStateCodes=true' as a connection property, it defaults to
      'false' in this release, so that we don't break legacy applications (it
      defaults to 'true' starting with Connector/J 3.1).

    - Fixed BUG#7601, PreparedStatement.fixDecimalExponent() adding extra
      '+', making number unparseable by MySQL server.

    - Escape sequence {fn convert(..., type)} now supports ODBC-style types
      that are prepended by 'SQL_'.

    - Fixed duplicated code in configureClientCharset() that prevented
      useOldUTF8Behavior=true from working properly.

    - Handle streaming result sets with > 2 billion rows properly by fixing
      wraparound of row number counter.

    - Fixed BUG#7607 - MS932, SHIFT_JIS and Windows_31J not recog. as
      aliases for sjis.

    - Fixed BUG#6549 (while fixing #7607), adding 'CP943' to aliases for
      sjis.

    - Fixed BUG#8064, which requires hex escaping of binary data when using
      multi-byte charsets with prepared statements.

    - Fixed BUG#8812, NON_UNIQUE column from DBMD.getIndexInfo() returned
      inverted value.

    - Workaround for server BUG#9098 - default values of CURRENT_* for
      DATE/TIME/TIMESTAMP/TIMESTAMP columns can't be distinguished from
      'string' values, so UpdatableResultSet.moveToInsertRow() generates
      bad SQL for inserting default values.

    - Fixed BUG#8629 - 'EUCKR' charset is sent as 'SET NAMES euc_kr' which
      MySQL-4.1 and newer doesn't understand.

    - DatabaseMetaData.supportsSelectForUpdate() returns correct value based
      on server version.

    - Use hex escapes for PreparedStatement.setBytes() for double-byte charsets
      including 'aliases' Windows-31J, CP934, MS932.

    - Added support for the "EUC_JP_Solaris" character encoding, which maps
      to a MySQL encoding of "eucjpms" (backported from 3.1 branch). This only
      works on servers that support eucjpms, namely 5.0.3 or later.

11-15-04 - Version 3.0.16-ga

    - Re-issue character set configuration commands when re-using pooled
      connections and/or Connection.changeUser() when connected to MySQL-4.1
      or newer.

    - Fixed ResultSetMetaData.isReadOnly() to detect non-writable columns
      when connected to MySQL-4.1 or newer, based on existence of 'original'
      table and column names.

    - Fixed BUG#5664, ResultSet.updateByte() when on insert row
      throws ArrayOutOfBoundsException.

    - Fixed DatabaseMetaData.getTypes() returning incorrect (i.e. non-negative)
      scale for the 'NUMERIC' type.

    - Fixed BUG#6198, off-by-one bug in Buffer.readString(string).

    - Made TINYINT(1) -> BIT/Boolean conversion configurable via 'tinyInt1isBit'
      property (default 'true' to be JDBC compliant out of the box).

    - Only set 'character_set_results' during connection establishment if
      server version >= 4.1.1.

    - Fixed regression where useUnbufferedInput was defaulting to 'false'.

    - Fixed BUG#6231, ResultSet.getTimestamp() on a column with TIME in it
      fails.

09-04-04 - Version 3.0.15-production

    - Fixed BUG#4010 - StringUtils.escapeEasternUnicodeByteStream is still
      broken for GBK

    - Fixed BUG#4334 - Failover for autoReconnect not using port #'s for any
      hosts, and not retrying all hosts. (WARN: This required a change to
      the SocketFactory connect() method signature, which is now

       public Socket connect(String host, int portNumber, Properties props)

      therefore any third-party socket factories will have to be changed
      to support this signature.

    - Logical connections created by MysqlConnectionPoolDataSource will
      now issue a rollback() when they are closed and sent back to the pool.
      If your application server/connection pool already does this for you, you
      can set the 'rollbackOnPooledClose' property to false to avoid the
      overhead of an extra rollback().

    - Removed redundant calls to checkRowPos() in ResultSet.

    - Fixed BUG#4742, 'DOUBLE' mapped twice in DBMD.getTypeInfo().

    - Added FLOSS license exemption.

    - Fixed BUG#4808, calling .close() twice on a PooledConnection causes NPE.

    - Fixed BUG#4138 and BUG#4860, DBMD.getColumns() returns incorrect JDBC
      type for unsigned columns. This affects type mappings for all numeric
      types in the RSMD.getColumnType() and RSMD.getColumnTypeNames() methods
      as well, to ensure that 'like' types from DBMD.getColumns() match up
      with what RSMD.getColumnType() and getColumnTypeNames() return.

    - 'Production' - 'GA' in naming scheme of distributions.

    - Fix for BUG#4880, RSMD.getPrecision() returning 0 for non-numeric types
      (should return max length in chars for non-binary types, max length
      in bytes for binary types). This fix also fixes mapping of
      RSMD.getColumnType() and RSMD.getColumnTypeName() for the BLOB types based
      on the length sent from the server (the server doesn't distinguish between
      TINYBLOB, BLOB, MEDIUMBLOB or LONGBLOB at the network protocol level).

    - Fixed BUG#5022 - ResultSet should release Field[] instance in .close().

    - Fixed BUG#5069 -- ResultSet.getMetaData() should not return
      incorrectly-initialized metadata if the result set has been closed, but
      should instead throw a SQLException. Also fixed for getRow() and
      getWarnings() and traversal methods by calling checkClosed() before
      operating on instance-level fields that are nullified during .close().

    - Parse new timezone variables from 4.1.x servers.

    - Use _binary introducer for PreparedStatement.setBytes() and
      set*Stream() when connected to MySQL-4.1.x or newer to avoid
      misinterpretation during character conversion.

05-28-04 - Version 3.0.14-production

    - Fixed URL parsing error

05-27-04 - Version 3.0.13-production

    - Fixed BUG#3848 - Using a MySQLDatasource without server name fails

    - Fixed BUG#3920 - "No Database Selected" when using
    MysqlConnectionPoolDataSource.

    - Fixed BUG#3873 - PreparedStatement.getGeneratedKeys() method returns only
    1 result for batched insertions

05-18-04 - Version 3.0.12-production

    - Add unsigned attribute to DatabaseMetaData.getColumns() output
    in the TYPE_NAME column.

    - Added 'failOverReadOnly' property, to allow end-user to configure
    state of connection (read-only/writable) when failed over.

    - Backported 'change user' and 'reset server state' functionality
      from 3.1 branch, to allow clients of MysqlConnectionPoolDataSource
      to reset server state on getConnection() on a pooled connection.

    - Don't escape SJIS/GBK/BIG5 when using MySQL-4.1 or newer.

    - Allow 'url' parameter for MysqlDataSource and MysqlConnectionPool
      DataSource so that passing of other properties is possible from
      inside appservers.

    - Map duplicate key and foreign key errors to SQLState of
      '23000'.

    - Backport documentation tooling from 3.1 branch.

    - Return creating statement for ResultSets created by
      getGeneratedKeys() (BUG#2957)

    - Allow java.util.Date to be sent in as parameter to
      PreparedStatement.setObject(), converting it to a Timestamp
      to maintain full precision (BUG#3103).

    - Don't truncate BLOBs/CLOBs when using setBytes() and/or
      setBinary/CharacterStream() (BUG#2670).

    - Dynamically configure character set mappings for field-level
      character sets on MySQL-4.1.0 and newer using 'SHOW COLLATION'
      when connecting.

    - Map 'binary' character set to 'US-ASCII' to support DATETIME
      charset recognition for servers >= 4.1.2

    - Use 'SET character_set_results" during initialization to allow any
      charset to be returned to the driver for result sets.

    - Use charsetnr returned during connect to encode queries before
      issuing 'SET NAMES' on MySQL >= 4.1.0.

    - Add helper methods to ResultSetMetaData (getColumnCharacterEncoding()
      and getColumnCharacterSet()) to allow end-users to see what charset
      the driver thinks it should be using for the column.

    - Only set character_set_results for MySQL >= 4.1.0.

    - Fixed BUG#3511, StringUtils.escapeSJISByteStream() not covering all
      eastern double-byte charsets correctly.

    - Renamed StringUtils.escapeSJISByteStream() to more appropriate
      escapeEasternUnicodeByteStream().

    - Fixed BUG#3554 - Not specifying database in URL caused MalformedURL
      exception.

    - Auto-convert MySQL encoding names to Java encoding names if used
      for characterEncoding property.

    - Added encoding names that are recognized on some JVMs to fix case
      where they were reverse-mapped to MySQL encoding names incorrectly.

    - Use junit.textui.TestRunner for all unit tests (to allow them to be
      run from the command line outside of Ant or Eclipse).

    - Fixed BUG#3557 - UpdatableResultSet not picking up default values
      for moveToInsertRow().

    - Fixed BUG#3570 - inconsistent reporting of column type. The server
      still doesn't return all types for *BLOBs *TEXT correctly, so the
      driver won't return those correctly.

    - Fixed BUG#3520 -- DBMD.getSQLStateType() returns incorrect value.

    - Fixed regression in PreparedStatement.setString() and eastern character
      encodings.

    - Made StringRegressionTest 4.1-unicode aware.

02-19-04 - Version 3.0.11-stable

    - Trigger a 'SET NAMES utf8' when encoding is forced to 'utf8' _or_
    'utf-8' via the 'characterEncoding' property. Previously, only the
    Java-style encoding name of 'utf-8' would trigger this.

    - AutoReconnect time was growing faster than exponentially (BUG#2447).

    - Fixed failover always going to last host in list (BUG#2578)

    - Added 'useUnbufferedInput' parameter, and now use it by default
      (due to JVM issue
      http://developer.java.sun.com/developer/bugParade/bugs/4401235.html)

    - Detect 'on/off' or '1','2','3' form of lower_case_table_names on
      server.

    - Return 'java.lang.Integer' for TINYINT and SMALLINT types from
      ResultSetMetaData.getColumnClassName() (fix for BUG#2852).

    - Return 'java.lang.Double' for FLOAT type from ResultSetMetaData.
      getColumnClassName() (fix for BUG#2855).

    - Return '[B' instead of java.lang.Object for BINARY, VARBINARY and
      LONGVARBINARY types from ResultSetMetaData.getColumnClassName()
      (JDBC compliance).

    - Issue connection events on all instances created from a
      ConnectionPoolDataSource.

01-13-04 - Version 3.0.10-stable

    - Don't count quoted id's when inside a 'string' in PreparedStatement
      parsing (fix for BUG#1511).

    - 'Friendlier' exception message for PacketTooLargeException
       (BUG#1534).

    - Backported fix for aliased tables and UpdatableResultSets in
      checkUpdatability() method from 3.1 branch.

    - Fix for ArrayIndexOutOfBounds exception when using Statement.setMaxRows()
      (BUG#1695).

    - Fixed BUG#1576, dealing with large blobs and split packets not being
      read correctly.

    - Fixed regression of Statement.getGeneratedKeys() and REPLACE statements.

    - Fixed BUG#1630, subsequent call to ResultSet.updateFoo() causes NPE if
      result set is not updatable.

    - Fix for 4.1.1-style auth with no password.

    - Fix for BUG#1731, Foreign Keys column sequence is not consistent in
      DatabaseMetaData.getImported/Exported/CrossReference().

    - Fix for BUG#1775 - DatabaseMetaData.getSystemFunction() returning
      bad function 'VResultsSion'.

    - Fix for BUG#1592 -- cross-database updatable result sets
      are not checked for updatability correctly.

    - DatabaseMetaData.getColumns() should return Types.LONGVARCHAR for
      MySQL LONGTEXT type.

    - ResultSet.getObject() on TINYINT and SMALLINT columns should return
      Java type 'Integer' (BUG#1913)

    - Added 'alwaysClearStream' connection property, which causes the driver
      to always empty any remaining data on the input stream before
      each query.

    - Added more descriptive error message 'Server Configuration Denies
      Access to DataSource', as well as retrieval of message from server.

    - Autoreconnect code didn't set catalog upon reconnect if it had been
      changed.

    - Implement ResultSet.updateClob().

    - ResultSetMetaData.isCaseSensitive() returned wrong value for CHAR/VARCHAR
      columns.

    - Fix for BUG#1933 -- Connection property "maxRows" not honored.

    - Fix for BUG#1925 -- Statements being created too many times in
      DBMD.extractForeignKeyFromCreateTable().

    - Fix for BUG#1914 -- Support escape sequence {fn convert ... }

    - Fix for BUG#1958 -- ArrayIndexOutOfBounds when parameter number ==
      number of parameters + 1.

    - Fix for BUG#2006 -- ResultSet.findColumn() should use first matching
      column name when there are duplicate column names in SELECT query
      (JDBC-compliance).

    - Removed static synchronization bottleneck from
      PreparedStatement.setTimestamp().

    - Removed static synchronization bottleneck from instance factory
      method of SingleByteCharsetConverter.

    - Enable caching of the parsing stage of prepared statements via
      the 'cachePrepStmts', 'prepStmtCacheSize' and 'prepStmtCacheSqlLimit'
      properties (disabled by default).

    - Speed up parsing of PreparedStatements, try to use one-pass whenever
      possible.

    - Fixed security exception when used in Applets (applets can't
      read the system property 'file.encoding' which is needed
      for LOAD DATA LOCAL INFILE).

    - Use constants for SQLStates.

    - Map charset 'ko18_ru' to 'ko18r' when connected to MySQL-4.1.0 or
      newer.

    - Ensure that Buffer.writeString() saves room for the \0.

    - Fixed exception 'Unknown character set 'danish' on connect w/ JDK-1.4.0

    - Fixed mappings in SQLError to report deadlocks with SQLStates of '41000'.

    - 'maxRows' property would affect internal statements, so check it for all
      statement creation internal to the driver, and set to 0 when it is not.

10-07-03 - Version 3.0.9-stable

    - Faster date handling code in ResultSet and PreparedStatement (no longer
      uses Date methods that synchronize on static calendars).

    - Fixed test for end of buffer in Buffer.readString().

    - Fixed ResultSet.previous() behavior to move current
      position to before result set when on first row
      of result set (bugs.mysql.com BUG#496)

    - Fixed Statement and PreparedStatement issuing bogus queries
      when setMaxRows() had been used and a LIMIT clause was present
      in the query.

    - Fixed BUG#661 - refreshRow didn't work when primary key values
      contained values that needed to be escaped (they ended up being
      doubly-escaped).

    - Support InnoDB contraint names when extracting foreign key info
      in DatabaseMetaData BUG#517 and BUG#664
      (impl. ideas from Parwinder Sekhon)

    - Backported 4.1 protocol changes from 3.1 branch (server-side SQL
      states, new field info, larger client capability flags,
      connect-with-database, etc).

    - Fix UpdatableResultSet to return values for getXXX() when on
      insert row (BUG#675).

    - The insertRow in an UpdatableResultSet is now loaded with
      the default column values when moveToInsertRow() is called
      (BUG#688)

    - DatabaseMetaData.getColumns() wasn't returning NULL for
      default values that are specified as NULL.

    - Change default statement type/concurrency to TYPE_FORWARD_ONLY
      and CONCUR_READ_ONLY (spec compliance).

    - Don't try and reset isolation level on reconnect if MySQL doesn't
      support them.

    - Don't wrap SQLExceptions in RowDataDynamic.

    - Don't change timestamp TZ twice if useTimezone==true (BUG#774)

    - Fixed regression in large split-packet handling (BUG#848).

    - Better diagnostic error messages in exceptions for 'streaming'
      result sets.

    - Issue exception on ResultSet.getXXX() on empty result set (wasn't
      caught in some cases).

    - Don't hide messages from exceptions thrown in I/O layers.

    - Don't fire connection closed events when closing pooled connections, or
      on PooledConnection.getConnection() with already open connections (BUG#884).

    - Clip +/- INF (to smallest and largest representative values for the type in
      MySQL) and NaN (to 0) for setDouble/setFloat(), and issue a warning on the
      statement when the server does not support +/- INF or NaN.

    - Fix for BUG#879, double-escaping of '\' when charset is SJIS or GBK and '\'
      appears in non-escaped input.

    - When emptying input stream of unused rows for 'streaming' result sets,
      have the current thread yield() every 100 rows in order to not monopolize
      CPU time.

    - Fixed BUG#1099, DatabaseMetaData.getColumns() getting confused about the
      keyword 'set' in character columns.

    - Fixed deadlock issue with Statement.setMaxRows().

    - Fixed CLOB.truncate(), BUG#1130

    - Optimized CLOB.setChracterStream(), BUG#1131

    - Made databaseName, portNumber and serverName optional parameters
      for MysqlDataSourceFactory (BUG#1246)

    - Fix for BUG#1247 -- ResultSet.get/setString mashing char 127

    - Backported auth. changes for 4.1.1 and newer from 3.1 branch.

    - Added com.mysql.jdbc.util.BaseBugReport to help creation of testcases
      for bug reports.

    - Added property to 'clobber' streaming results, by setting the
      'clobberStreamingResults' property to 'true' (the default is 'false').
      This will cause a 'streaming' ResultSet to be automatically
      closed, and any oustanding data still streaming from the server to
      be discarded if another query is executed before all the data has been
      read from the server.

05-23-03 - Version 3.0.8-stable

    - Allow bogus URLs in Driver.getPropertyInfo().

    - Return list of generated keys when using multi-value INSERTS
      with Statement.getGeneratedKeys().

    - Use JVM charset with filenames and 'LOAD DATA [LOCAL] INFILE'

    - Fix infinite loop with Connection.cleanup().

    - Changed Ant target 'compile-core' to 'compile-driver', and
      made testsuite compilation a separate target.

    - Fixed result set not getting set for Statement.executeUpdate(),
      which affected getGeneratedKeys() and getUpdateCount() in
      some cases.

    - Unicode character 0xFFFF in a string would cause the driver to
      throw an ArrayOutOfBoundsException (Bug #378)

    - Return correct amount of generated keys when using 'REPLACE'
      statements.

    - Fix problem detecting server character set in some cases.

    - Fix row data decoding error when using _very_ large packets.

    - Optimized row data decoding.

    - Issue exception when operating on an already-closed
      prepared statement.

    - Fixed SJIS encoding bug, thanks to Naoto Sato.

    - Optimized usage of EscapeProcessor.

    - Allow multiple calls to Statement.close()

04-08-03 - Version 3.0.7-stable

    - Fixed MysqlPooledConnection.close() calling wrong event type.

    - Fixed StringIndexOutOfBoundsException in PreparedStatement.
      setClob().

    - 4.1 Column Metadata fixes

    - Remove synchronization from Driver.connect() and
      Driver.acceptsUrl().

    - IOExceptions during a transaction now cause the Connection to
      be closed.

    - Fixed missing conversion for 'YEAR' type in ResultSetMetaData.
      getColumnTypeName().

    - Don't pick up indexes that start with 'pri' as primary keys
      for DBMD.getPrimaryKeys().

    - Throw SQLExceptions when trying to do operations on a forcefully
      closed Connection (i.e. when a communication link failure occurs).

    - You can now toggle profiling on/off using
      Connection.setProfileSql(boolean).

    - Fixed charset issues with database metadata (charset was not
      getting set correctly).

    - Updatable ResultSets can now be created for aliased tables/columns
      when connected to MySQL-4.1 or newer.

    - Fixed 'LOAD DATA LOCAL INFILE' bug when file > max_allowed_packet.

    - Fixed escaping of 0x5c ('\') character for GBK and Big5 charsets.

    - Fixed ResultSet.getTimestamp() when underlying field is of type DATE.

    - Ensure that packet size from alignPacketSize() does not
      exceed MAX_ALLOWED_PACKET (JVM bug)

    - Don't reset Connection.isReadOnly() when autoReconnecting.

02-18-03 - Version 3.0.6-stable

    - Fixed ResultSetMetaData to return "" when catalog not known.
      Fixes NullPointerExceptions with Sun's CachedRowSet.

    - Fixed DBMD.getTypeInfo() and DBMD.getColumns() returning
      different value for precision in TEXT/BLOB types.

    - Allow ignoring of warning for 'non transactional tables' during
      rollback (compliance/usability) by setting 'ignoreNonTxTables'
      property to 'true'.

    - Fixed SQLExceptions getting swallowed on initial connect.

    - Fixed Statement.setMaxRows() to stop sending 'LIMIT' type queries
      when not needed (performance)

    - Clean up Statement query/method mismatch tests (i.e. INSERT not
      allowed with .executeQuery()).

    - More checks added in ResultSet traversal method to catch
      when in closed state.

    - Fixed ResultSetMetaData.isWritable() to return correct value.

    - Add 'window' of different NULL sorting behavior to
      DBMD.nullsAreSortedAtStart (4.0.2 to 4.0.10, true, otherwise,
      no).

    - Implemented Blob.setBytes(). You still need to pass the
      resultant Blob back into an updatable ResultSet or
      PreparedStatement to persist the changes, as MySQL does
      not support 'locators'.

    - Backported 4.1 charset field info changes from Connector/J 3.1

01-22-03 - Version 3.0.5-gamma

    - Fixed Buffer.fastSkipLenString() causing ArrayIndexOutOfBounds
      exceptions with some queries when unpacking fields.

    - Implemented an empty TypeMap for Connection.getTypeMap() so that
      some third-party apps work with MySQL (IBM WebSphere 5.0 Connection
      pool).

    - Added missing LONGTEXT type to DBMD.getColumns().

    - Retrieve TX_ISOLATION from database for
      Connection.getTransactionIsolation() when the MySQL version
      supports it, instead of an instance variable.

    - Quote table names in DatabaseMetaData.getColumns(),
      getPrimaryKeys(), getIndexInfo(), getBestRowIdentifier()

    - Greatly reduce memory required for setBinaryStream() in
      PreparedStatements.

    - Fixed ResultSet.isBeforeFirst() for empty result sets.

    - Added update options for foreign key metadata.


01-06-03 - Version 3.0.4-gamma

    - Added quoted identifiers to database names for
      Connection.setCatalog.

    - Added support for quoted identifiers in PreparedStatement
      parser.

    - Streamlined character conversion and byte[] handling in
      PreparedStatements for setByte().

    - Reduce memory footprint of PreparedStatements by sharing
      outbound packet with MysqlIO.

    - Added 'strictUpdates' property to allow control of amount
      of checking for 'correctness' of updatable result sets. Set this
      to 'false' if you want faster updatable result sets and you know
      that you create them from SELECTs on tables with primary keys and
      that you have selected all primary keys in your query.

    - Added support for 4.0.8-style large packets.

    - Fixed PreparedStatement.executeBatch() parameter overwriting.

12-17-02 - Version 3.0.3-dev

    - Changed charsToByte in SingleByteCharConverter to be non-static

    - Changed SingleByteCharConverter to use lazy initialization of each
      converter.

    - Fixed charset handling in Fields.java

    - Implemented Connection.nativeSQL()

    - More robust escape tokenizer -- recognize '--' comments, and allow
      nested escape sequences (see testsuite.EscapeProcessingTest)

    - DBMD.getImported/ExportedKeys() now handles multiple foreign keys
      per table.

    - Fixed ResultSetMetaData.getPrecision() returning incorrect values
      for some floating point types.

    - Fixed ResultSetMetaData.getColumnTypeName() returning BLOB for
      TEXT and TEXT for BLOB types.

    - Fixed Buffer.isLastDataPacket() for 4.1 and newer servers.

    - Added CLIENT_LONG_FLAG to be able to get more column flags
      (isAutoIncrement() being the most important)

    - Because of above, implemented ResultSetMetaData.isAutoIncrement()
      to use Field.isAutoIncrement().

    - Honor 'lower_case_table_names' when enabled in the server when
      doing table name comparisons in DatabaseMetaData methods.

    - Some MySQL-4.1 protocol support (extended field info from selects)

    - Use non-aliased table/column names and database names to fullly
      qualify tables and columns in UpdatableResultSet (requires
      MySQL-4.1 or newer)

    - Allow user to alter behavior of Statement/
      PreparedStatement.executeBatch() via 'continueBatchOnError' property
      (defaults to 'true').

    - Check for connection closed in more Connection methods
      (createStatement, prepareStatement, setTransactionIsolation,
      setAutoCommit).

    - More robust implementation of updatable result sets. Checks that
      _all_ primary keys of the table have been selected.

    - 'LOAD DATA LOCAL INFILE ...' now works, if your server is configured
      to allow it. Can be turned off with the 'allowLoadLocalInfile'
      property (see the README).

    - Substitute '?' for unknown character conversions in single-byte
      character sets instead of '\0'.

    - NamedPipeSocketFactory now works (only intended for Windows), see
      README for instructions.

11-08-02 - Version 3.0.2-dev

    - Fixed issue with updatable result sets and PreparedStatements not
      working

    - Fixed ResultSet.setFetchDirection(FETCH_UNKNOWN)

    - Fixed issue when calling Statement.setFetchSize() when using
      arbitrary values

    - Fixed incorrect conversion in ResultSet.getLong()

    - Implemented ResultSet.updateBlob().

    - Removed duplicate code from UpdatableResultSet (it can be inherited
      from ResultSet, the extra code for each method to handle updatability
      I thought might someday be necessary has not been needed).

    - Fixed "UnsupportedEncodingException" thrown when "forcing" a
      character encoding via properties.

    - Fixed various non-ASCII character encoding issues.

    - Added driver property 'useHostsInPrivileges'. Defaults to true.
      Affects whether or not '@hostname' will be used in
      DBMD.getColumn/TablePrivileges.

    - All DBMD result set columns describing schemas now return NULL
      to be more compliant with the behavior of other JDBC drivers
      for other databases (MySQL does not support schemas).

    - Added SSL support. See README for information on how to use it.

    - Properly restore connection properties when autoReconnecting
      or failing-over, including autoCommit state, and isolation level.

    - Use 'SHOW CREATE TABLE' when possible for determining foreign key
      information for DatabaseMetaData...also allows cascade options for
      DELETE information to be returned

    - Escape 0x5c character in strings for the SJIS charset.

    - Fixed start position off-by-1 error in Clob.getSubString()

    - Implemented Clob.truncate()

    - Implemented Clob.setString()

    - Implemented Clob.setAsciiStream()

    - Implemented Clob.setCharacterStream()

    - Added com.mysql.jdbc.MiniAdmin class, which allows you to send
      'shutdown' command to MySQL server...Intended to be used when 'embedding'
      Java and MySQL server together in an end-user application.

    - Added 'connectTimeout' parameter that allows users of JDK-1.4 and newer
      to specify a maxium time to wait to establish a connection.

    - Failover and autoReconnect only work when the connection is in a
      autoCommit(false) state, in order to stay transaction safe

    - Added 'queriesBeforeRetryMaster' property that specifies how many
      queries to issue when failed over before attempting to reconnect
      to the master (defaults to 50)

    - Fixed DBMD.supportsResultSetConcurrency() so that it returns true
      for ResultSet.TYPE_SCROLL_INSENSITIVE and ResultSet.CONCUR_READ_ONLY or
      ResultSet.CONCUR_UPDATABLE

    - Fixed ResultSet.isLast() for empty result sets (should return false).

    - PreparedStatement now honors stream lengths in setBinary/Ascii/Character
      Stream() unless you set the connection property
      'useStreamLengthsInPrepStmts' to 'false'.

    - Removed some not-needed temporary object creation by using Strings
      smarter in EscapeProcessor, Connection and DatabaseMetaData classes.

09-21-02 - Version 3.0.1-dev

    - Fixed ResultSet.getRow() off-by-one bug.

    - Fixed RowDataStatic.getAt() off-by-one bug.

    - Added limited Clob functionality (ResultSet.getClob(),
      PreparedStatemtent.setClob(),
      PreparedStatement.setObject(Clob).

    - Added socketTimeout parameter to URL.

    - Connection.isClosed() no longer "pings" the server.

    - Connection.close() issues rollback() when getAutoCommit() == false

    - Added "paranoid" parameter...sanitizes error messages removing
      "sensitive" information from them (i.e. hostnames, ports,
      usernames, etc.), as well as clearing "sensitive" data structures
      when possible.

    - Fixed ResultSetMetaData.isSigned() for TINYINT and BIGINT.

    - Charsets now automatically detected. Optimized code for single-byte
      character set conversion.

    - Implemented ResultSet.getCharacterStream()

    - Added "LOCAL TEMPORARY" to table types in DatabaseMetaData.getTableTypes()

    - Massive code clean-up to follow Java coding conventions (the time had come)


07-31-02 - Version 3.0.0-dev

    - !!! LICENSE CHANGE !!! The driver is now GPL. If you need
      non-GPL licenses, please contact me <[email protected]>

    - JDBC-3.0 functionality including
      Statement/PreparedStatement.getGeneratedKeys() and
      ResultSet.getURL()

    - Performance enchancements - driver is now 50-100% faster
      in most situations, and creates fewer temporary objects

    - Repackaging...new driver name is "com.mysql.jdbc.Driver",
      old name still works, though (the driver is now provided
      by MySQL-AB)

    - Better checking for closed connections in Statement
      and PreparedStatement.

    - Support for streaming (row-by-row) result sets (see README)
      Thanks to Doron.

    - Support for large packets (new addition to MySQL-4.0 protocol),
      see README for more information.

    - JDBC Compliance -- Passes all tests besides stored procedure tests


    - Fix and sort primary key names in DBMetaData (SF bugs 582086 and 582086)

    - Float types now reported as java.sql.Types.FLOAT (SF bug 579573)

    - ResultSet.getTimestamp() now works for DATE types (SF bug 559134)

    - ResultSet.getDate/Time/Timestamp now recognizes all forms of invalid
      values that have been set to all zeroes by MySQL (SF bug 586058)

    - Testsuite now uses Junit (which you can get from www.junit.org)

    - The driver now only works with JDK-1.2 or newer.

    - Added multi-host failover support (see README)

    - General source-code cleanup.

    - Overall speed improvements via controlling transient object
      creation in MysqlIO class when reading packets

    - Performance improvements in  string handling and field
      metadata creation (lazily instantiated) contributed by
      Alex Twisleton-Wykeham-Fiennes


05-16-02 - Version 2.0.14

    - More code cleanup

    - PreparedStatement now releases resources on .close() (SF bug 553268)

    - Quoted identifiers not used if server version does not support them. Also,
      if server started with --ansi or --sql-mode=ANSI_QUOTES then '"' will be
      used as an identifier quote, otherwise '`' will be used.

    - ResultSet.getDouble() now uses code built into JDK to be more precise (but slower)

    - LogicalHandle.isClosed() calls through to physical connection

    - Added SQL profiling (to STDERR). Set "profileSql=true" in your JDBC url.
      See README for more information.

    - Fixed typo for relaxAutoCommit parameter.

04-24-02 - Version 2.0.13

    - More code cleanup.

    - Fixed unicode chars being read incorrectly (SF bug 541088)

    - Faster blob escaping for PrepStmt

    - Added set/getPortNumber() to DataSource(s) (SF bug 548167)

    - Added setURL() to MySQLXADataSource (SF bug 546019)

    - PreparedStatement.toString() fixed (SF bug 534026)

    - ResultSetMetaData.getColumnClassName() now implemented

    - Rudimentary version of Statement.getGeneratedKeys() from JDBC-3.0
      now implemented (you need to be using JDK-1.4 for this to work, I
      believe)

    - DBMetaData.getIndexInfo() - bad PAGES fixed (SF BUG 542201)

04-07-02 - Version 2.0.12

    - General code cleanup.

    - Added getIdleFor() method to Connection and MysqlLogicalHandle.

    - Relaxed synchronization in all classes, should fix 520615 and 520393.

    - Added getTable/ColumnPrivileges() to DBMD (fixes 484502).

    - Added new types to getTypeInfo(), fixed existing types thanks to
      Al Davis and Kid Kalanon.

    - Added support for BIT types (51870) to PreparedStatement.

    - Fixed getRow() bug (527165) in ResultSet

    - Fixes for ResultSet updatability in PreparedStatement.
    - Fixed timezone off by 1-hour bug in PreparedStatement (538286, 528785).

    - ResultSet: Fixed updatability (values being set to null
      if not updated).

    - DataSources - fixed setUrl bug (511614, 525565),
      wrong datasource class name (532816, 528767)

    - Added identifier quoting to all DatabaseMetaData methods
      that need them (should fix 518108)

    - Added support for YEAR type (533556)

    - ResultSet.insertRow() should now detect auto_increment fields
      in most cases and use that value in the new row. This detection
      will not work in multi-valued keys, however, due to the fact that
      the MySQL protocol does not return this information.

    - ResultSet.refreshRow() implemented.

    - Fixed testsuite.Traversal afterLast() bug, thanks to Igor Lastric.

01-27-02 - Version 2.0.11

    - Fixed missing DELETE_RULE value in
      DBMD.getImported/ExportedKeys() and getCrossReference().

    - Full synchronization of Statement.java.

    - More changes to fix "Unexpected end of input stream"
      errors when reading BLOBs. This should be the last fix.

01-24-02 - Version 2.0.10

     - Fixed spurious "Unexpected end of input stream" errors in
       MysqlIO (bug 507456).

     - Fixed null-pointer-exceptions when using
       MysqlConnectionPoolDataSource with Websphere 4 (bug 505839).

01-13-02 - Version 2.0.9

     - Ant build was corrupting included jar files, fixed
       (bug 487669).

     - Fixed extra memory allocation in MysqlIO.readPacket()
       (bug 488663).

     - Implementation of DatabaseMetaData.getExported/ImportedKeys() and
       getCrossReference().

     - Full synchronization on methods modifying instance and class-shared
       references, driver should be entirely thread-safe now (please
       let me know if you have problems)

     - DataSource implementations moved to org.gjt.mm.mysql.jdbc2.optional
       package, and (initial) implementations of PooledConnectionDataSource
       and XADataSource are in place (thanks to Todd Wolff for the
       implementation and testing of PooledConnectionDataSource with
       IBM WebSphere 4).

     - Added detection of network connection being closed when reading packets
       (thanks to Todd Lizambri).

     - Fixed quoting error with escape processor (bug 486265).

     - Report batch update support through DatabaseMetaData (bug 495101).

     - Fixed off-by-one-hour error in PreparedStatement.setTimestamp()
       (bug 491577).

     - Removed concatenation support from driver (the '||' operator),
       as older versions of VisualAge seem to be the only thing that
       use it, and it conflicts with the logical '||' operator. You will
       need to start mysqld with the "--ansi" flag to use the '||'
       operator as concatenation (bug 491680)

     - Fixed casting bug in PreparedStatement (bug 488663).

11-25-01 - Version 2.0.8

     - Batch updates now supported (thanks to some inspiration
       from Daniel Rall).

     - XADataSource/ConnectionPoolDataSource code (experimental)

     - PreparedStatement.setAnyNumericType() now handles positive
       exponents correctly (adds "+" so MySQL can understand it).

     - DatabaseMetaData.getPrimaryKeys() and getBestRowIdentifier()
       are now more robust in identifying primary keys (matches
       regardless of case or abbreviation/full spelling of Primary Key
       in Key_type column).

10-24-01 - Version 2.0.7

     - PreparedStatement.setCharacterStream() now implemented

     - Fixed dangling socket problem when in high availability
       (autoReconnect=true) mode, and finalizer for Connection will
       close any dangling sockets on GC.

     - Fixed ResultSetMetaData.getPrecision() returning one
       less than actual on newer versions of MySQL.

     - ResultSet.getBlob() now returns null if column value
       was null.

     - Character sets read from database if useUnicode=true
       and characterEncoding is not set. (thanks to
       Dmitry Vereshchagin)

     - Initial transaction isolation level read from
       database (if avaialable) (thanks to Dmitry Vereshchagin)

     - Fixed DatabaseMetaData.supportsTransactions(), and
       supportsTransactionIsolationLevel() and getTypeInfo()
       SQL_DATETIME_SUB and SQL_DATA_TYPE fields not being
       readable.

     - Fixed PreparedStatement generating SQL that would end
       up with syntax errors for some queries.

     - Fixed ResultSet.isAfterLast() always returning false.

     - Fixed timezone issue in PreparedStatement.setTimestamp()
       (thanks to Erik Olofsson)

     - Captialize type names when "captializeTypeNames=true"
       is passed in URL or properties (for WebObjects, thanks
       to Anjo Krank)

     - Updatable result sets now correctly handle NULL
       values in fields.

     - PreparedStatement.setDouble() now uses full-precision
       doubles (reverting a fix made earlier to truncate them).

     - PreparedStatement.setBoolean() will use 1/0 for values
       if your MySQL Version >= 3.21.23.

06-16-01 - Version 2.0.6

     - Fixed PreparedStatement parameter checking

     - Fixed case-sensitive column names in ResultSet.java

06-13-01 - Version 2.0.5

     - Fixed ResultSet.getBlob() ArrayIndex out-of-bounds

     - Fixed ResultSetMetaData.getColumnTypeName for TEXT/BLOB

     - Fixed ArrayIndexOutOfBounds when sending large BLOB queries
       (Max size packet was not being set)

     - Added ISOLATION level support to Connection.setIsolationLevel()

     - Fixed NPE on PreparedStatement.executeUpdate() when all columns
       have not been set.

     - Fixed data parsing of TIMESTAMPs with 2-digit years

     - Added Byte to PreparedStatement.setObject()

     - ResultSet.getBoolean() now recognizes '-1' as 'true'

     - ResultSet has +/-Inf/inf support

     - ResultSet.insertRow() works now, even if not all columns are
       set (they will be set to "NULL")

     - DataBaseMetaData.getCrossReference() no longer ArrayIndexOOB

     - getObject() on ResultSet correctly does TINYINT->Byte and
       SMALLINT->Short

12-03-00 - Version 2.0.3

     - Implemented getBigDecimal() without scale component
       for JDBC2.

     - Fixed composite key problem with updateable result sets.

     - Added detection of -/+INF for doubles.

     - Faster ASCII string operations.

     - Fixed incorrect detection of MAX_ALLOWED_PACKET, so sending
       large blobs should work now.

     - Fixed off-by-one error in java.sql.Blob implementation code.

     - Added "ultraDevHack" URL parameter, set to "true" to allow
       (broken) Macromedia UltraDev to use the driver.

04-06-00 - Version 2.0.1

     - Fixed RSMD.isWritable() returning wrong value.
       Thanks to Moritz Maass.

     - Cleaned up exception handling when driver connects

     - Columns that are of type TEXT now return as Strings
       when you use getObject()

     - DatabaseMetaData.getPrimaryKeys() now works correctly wrt
       to key_seq. Thanks to Brian Slesinsky.

     - No escape processing is done on PreparedStatements anymore
       per JDBC spec.

     - Fixed many JDBC-2.0 traversal, positioning bugs, especially
       wrt to empty result sets. Thanks to Ron Smits, Nick Brook,
       Cessar Garcia and Carlos Martinez.

     - Fixed some issues with updatability support in ResultSet when
       using multiple primary keys.

02-21-00 - Version 2.0pre5

     - Fixed Bad Handshake problem.

01-10-00 - Version 2.0pre4

     - Fixes to ResultSet for insertRow() - Thanks to
       Cesar Garcia

     - Fix to Driver to recognize JDBC-2.0 by loading a JDBC-2.0
       class, instead of relying on JDK version numbers. Thanks
       to John Baker.

     - Fixed ResultSet to return correct row numbers

     - Statement.getUpdateCount() now returns rows matched,
       instead of rows actually updated, which is more SQL-92
       like.

10-29-99

     - Statement/PreparedStatement.getMoreResults() bug fixed.
       Thanks to Noel J. Bergman.

     - Added Short as a type to PreparedStatement.setObject().
       Thanks to Jeff Crowder

     - Driver now automagically configures maximum/preferred packet
       sizes by querying server.

     - Autoreconnect code uses fast ping command if server supports
       it.

     - Fixed various bugs wrt. to packet sizing when reading from
       the server and when alloc'ing to write to the server.

08-17-99 - Version 2.0pre

     - Now compiles under JDK-1.2. The driver supports both JDK-1.1
       and JDK-1.2 at the same time through a core set of classes.
       The driver will load the appropriate interface classes at
       runtime by figuring out which JVM version you are using.

     - Fixes for result sets with all nulls in the first row.
       (Pointed out by Tim Endres)

     - Fixes to column numbers in SQLExceptions in ResultSet
       (Thanks to Blas Rodriguez Somoza)

     - The database no longer needs to specified to connect.
       (Thanks to Christian Motschke)

07-04-99 - Version 1.2b

     - Better Documentation (in progress), in doc/mm.doc/book1.html

     - DBMD now allows null for a column name pattern (not in
       spec), which it changes to '%'.

     - DBMD now has correct types/lengths for getXXX().

     - ResultSet.getDate(), getTime(), and getTimestamp() fixes.
       (contributed by Alan Wilken)

     - EscapeProcessor now handles \{ \} and { or } inside quotes
       correctly. (thanks to Alik for some ideas on how to fix it)

     - Fixes to properties handling in Connection.
       (contributed by Juho Tikkala)

     - ResultSet.getObject() now returns null for NULL columns
       in the table, rather than bombing out.
       (thanks to Ben Grosman)

     - ResultSet.getObject() now returns Strings for types
       from MySQL that it doesn't know about. (Suggested by
       Chris Perdue)

     - Removed DataInput/Output streams, not needed, 1/2 number
       of method calls per IO operation.

     - Use default character encoding if one is not specified. This
       is a work-around for broken JVMs, because according to spec,
       EVERY JVM must support "ISO8859_1", but they don't.

     - Fixed Connection to use the platform character encoding
       instead of "ISO8859_1" if one isn't explicitly set. This
       fixes problems people were having loading the character-
       converter classes that didn't always exist (JVM bug).
       (thanks to Fritz Elfert for pointing out this problem)

     - Changed MysqlIO to re-use packets where possible to reduce
       memory usage.

     - Fixed escape-processor bugs pertaining to {} inside
       quotes.

04-14-99 - Version 1.2a

     - Fixed character-set support for non-Javasoft JVMs
       (thanks to many people for pointing it out)

     - Fixed ResultSet.getBoolean() to recognize 'y' & 'n'
       as well as '1' & '0' as boolean flags.
       (thanks to Tim Pizey)

     - Fixed ResultSet.getTimestamp() to give better performance.
       (thanks to Richard Swift)

     - Fixed getByte() for numeric types.
       (thanks to Ray Bellis)

     - Fixed DatabaseMetaData.getTypeInfo() for DATE type.
       (thanks to Paul Johnston)

     - Fixed EscapeProcessor for "fn" calls.
       (thanks to Piyush Shah at locomotive.org)

     - Fixed EscapeProcessor to not do extraneous work if there
       are no escape codes.
       (thanks to Ryan Gustafson)

     - Fixed Driver to parse URLs of the form "jdbc:mysql://host:port"
       (thanks to Richard Lobb)

03-24-99 - Version 1.1i

     - Fixed Timestamps for PreparedStatements

     - Fixed null pointer exceptions in RSMD and RS

     - Re-compiled with jikes for valid class files (thanks ms!)

03-08-99 - Version 1.1h

     - Fixed escape processor to deal with un-matched { and }
       (thanks to Craig Coles)

     - Fixed escape processor to create more portable (between
       DATETIME and TIMESTAMP types) representations so that
       it will work with BETWEEN clauses.
       (thanks to Craig Longman)

     - MysqlIO.quit() now closes the socket connection. Before,
       after many failed connections some OS's would run out
       of file descriptors. (thanks to Michael Brinkman)

     - Fixed NullPointerException in Driver.getPropertyInfo.
       (thanks to Dave Potts)

     - Fixes to MysqlDefs to allow all *text fields to be
       retrieved as Strings.
       (thanks to Chris at Leverage)

     - Fixed setDouble in PreparedStatement for large numbers
       to avoid sending scientific notation to the database.
       (thanks to J.S. Ferguson)

     - Fixed getScale() and getPrecision() in RSMD.
       (contrib'd by James Klicman)

     - Fixed getObject() when field was DECIMAL or NUMERIC
       (thanks to Bert Hobbs)

     - DBMD.getTables() bombed when passed a null table-name
       pattern. Fixed. (thanks to Richard Lobb)

     - Added check for "client not authorized" errors during
       connect. (thanks to Hannes Wallnoefer)

02-19-99 - Version 1.1g

     - Result set rows are now byte arrays. Blobs and Unicode
       work bidriectonally now. The useUnicode and encoding
       options are implemented now.

     - Fixes to PreparedStatement to send binary set by
       setXXXStream to be sent un-touched to the MySQL server.

     - Fixes to getDriverPropertyInfo().

12-31-98 - Version 1.1f

     - Changed all ResultSet fields to Strings, this should allow
       Unicode to work, but your JVM must be able to convert
       between the character sets. This should also make reading
       data from the server be a bit quicker, because there is now
       no conversion from StringBuffer to String.

     - Changed PreparedStatement.streamToString() to be more
       efficient (code from Uwe Schaefer).

     - URL parsing is more robust (throws SQL exceptions on errors
       rather than NullPointerExceptions)

     - PreparedStatement now can convert Strings to Time/Date values
       via setObject() (code from Robert Currey).

     - IO no longer hangs in Buffer.readInt(), that bug was
       introduced in 1.1d when changing to all byte-arrays for
       result sets. (Pointed out by Samo Login)

11-03-98 - Version 1.1b

     - Fixes to DatabaseMetaData to allow both IBM VA and J-Builder
       to work. Let me know how it goes. (thanks to Jac Kersing)

     - Fix to ResultSet.getBoolean() for NULL strings
       (thanks to Barry Lagerweij)

     - Beginning of code cleanup, and formatting. Getting ready
       to branch this off to a parallel JDBC-2.0 source tree.

     - Added "final" modifier to critical sections in MysqlIO and
       Buffer to allow compiler to inline methods for speed.

9-29-98

     - If object references passed to setXXX() in PreparedStatement are
       null, setNull() is automatically called for you. (Thanks for the
       suggestion goes to Erik Ostrom)

     - setObject() in PreparedStatement will now attempt to write a
       serialized  representation of the object to the database for
       objects of Types.OTHER and objects of unknown type.

     - Util now has a static method readObject() which given a ResultSet
       and a column index will re-instantiate an object serialized in
       the above manner.

9-02-98 - Vesion 1.1

     - Got rid of "ugly hack" in MysqlIO.nextRow(). Rather than
       catch an exception, Buffer.isLastDataPacket() was fixed.

     - Connection.getCatalog() and Connection.setCatalog()
       should work now.

     - Statement.setMaxRows() works, as well as setting
       by property maxRows. Statement.setMaxRows() overrides
       maxRows set via properties or url parameters.

     - Automatic re-connection is available. Because it has
       to "ping" the database before each query, it is
       turned off by default. To use it, pass in "autoReconnect=true"
       in the connection URL. You may also change the number of
       reconnect tries, and the initial timeout value via
       "maxReconnects=n" (default 3) and "initialTimeout=n"
       (seconds, default 2) parameters. The timeout is an
       exponential backoff type of timeout, e.g. if you have initial
       timeout of 2 seconds, and maxReconnects of 3, then the driver
       will timeout 2 seconds, 4 seconds, then 16 seconds between each
       re-connection attempt.

8-24-98 - Version 1.0

     - Fixed handling of blob data in Buffer.java

     - Fixed bug with authentication packet being
       sized too small.

     - The JDBC Driver is now under the LPGL

8-14-98 -

     - Fixed Buffer.readLenString() to correctly
          read data for BLOBS.

     - Fixed PreparedStatement.stringToStream to
          correctly read data for BLOBS.

     - Fixed PreparedStatement.setDate() to not
       add a day.
       (above fixes thanks to Vincent Partington)

     - Added URL parameter parsing (?user=... etc).


8-04-98 - Version 0.9d

     - Big news! New package name. Tim Endres from ICE
       Engineering is starting a new source tree for
       GNU GPL'd Java software. He's graciously given
       me the org.gjt.mm package directory to use, so now
       the driver is in the org.gjt.mm.mysql package scheme.
       I'm "legal" now. Look for more information on Tim's
       project soon.

     - Now using dynamically sized packets to reduce
       memory usage when sending commands to the DB.

     - Small fixes to getTypeInfo() for parameters, etc.

     - DatabaseMetaData is now fully implemented. Let me
       know if these drivers work with the various IDEs
       out there. I've heard that they're working with
       JBuilder right now.

     - Added JavaDoc documentation to the package.

     - Package now available in .zip or .tar.gz.

7-28-98 - Version 0.9

     - Implemented getTypeInfo().
       Connection.rollback() now throws an SQLException
       per the JDBC spec.

     - Added PreparedStatement that supports all JDBC API
       methods for PreparedStatement including InputStreams.
       Please check this out and let me know if anything is
       broken.

     - Fixed a bug in ResultSet that would break some
       queries that only returned 1 row.

     - Fixed bugs in DatabaseMetaData.getTables(),
       DatabaseMetaData.getColumns() and
       DatabaseMetaData.getCatalogs().

     - Added functionality to Statement that allows
       executeUpdate() to store values for IDs that are
       automatically generated for AUTO_INCREMENT fields.
       Basically, after an executeUpdate(), look at the
       SQLWarnings for warnings like "LAST_INSERTED_ID =
       'some number', COMMAND = 'your SQL query'".

       If you are using AUTO_INCREMENT fields in your
       tables and are executing a lot of executeUpdate()s
       on one Statement, be sure to clearWarnings() every
       so often to save memory.

7-06-98 - Version 0.8

     - Split MysqlIO and Buffer to separate classes. Some
       ClassLoaders gave an IllegalAccess error for some
       fields in those two classes. Now mm.mysql works in
       applets and all classloaders.

       Thanks to Joe Ennis <[email protected]> for pointing
       out the problem and working on a fix with me.

7-01-98 - Version 0.7

     - Fixed DatabaseMetadata problems in getColumns() and
       bug in switch statement in the Field constructor.

       Thanks to Costin Manolache <[email protected]> for
       pointing these out.

5-21-98 - Version 0.6

     - Incorporated efficiency changes from
       Richard Swift <[email protected]> in
       MysqlIO.java and ResultSet.java

     - We're now 15% faster than gwe's driver.

     - Started working on DatabaseMetaData.

       The following methods are implemented:
        * getTables()
        * getTableTypes()
        * getColumns
        * getCatalogs()