Download | Release Notes | Changelog |

Release date: 23 Mar 2016

MariaDB Connector/J 1.3.7 is a Stable (GA) release.

For a list of all changes made in this release, with links to detailed information on each push, see the changelog.

This version is a bugfix / performance improvement release.

Notable changes and additions

Major

• : Server prepare statement failover uses the associated connection

• Performance improvements :

  • using directly the query.getByte("UTF-8") array to avoid recreating a new array

  • rewriteStatement improvement (parsing query to verfy that query can be rewritten + performance)

Minor

• : getString on '0000-00-00' date was returning npe.

• PrepareStatement now doesn't lose decimal when using Float or Double object

| Release Notes | |

Release date: 9 Feb 2016

MariaDB Connector/J 1.3.5 is a (GA) release.

For a list of all changes made in this release, with links to detailed information on each push, see the .

This version is a bugfix release

Notable changes and additions

Download | Release Notes | Changelog |

Release date: 12 Jan 2016

MariaDB Connector/J 1.3.4 is a Stable (GA) release.

For a list of all changes made in this release, with links to detailed information on each push, see the changelog.

This version is a bugfix release

Notable changes and additions

Major

• Failover improvements (reconnection implementation evolution, thread handling ...)

• : Correction on using getInt on a signed smallInt negative value on prepareStatement

• : PrepareStatement prepare exception handling

Minor

• : Closing a close statement does not throw an Exception anymore

• : Permit commit when in autocommit mode

• : Permit using Connection.setReadOnly(true) during a transaction

Behavior change

On a master/slave cluster, the driver uses 2 underlying connections: one to a master instance, one to a slave instance. When one of the connections fails, if the driver needs it right away, it will create a new connection immediately before re-executing the query, if possible.

If the failed connection is not needed immediately, this driver will subscribe to the "failover reconnection" that will be handled in other threads. Failover threads will attempt to create a new connection to replace a failing one, so the interruption is minimal for the queries in progress. When the client asks to use a failed connection, the new connection created by the failover thread will replace the failed one.

Example: after a failure on a slave connection, readonly operations are temporary executed on the master connection to avoid interruption on the client side. The failover thread will then create a new slave connection that will replace the failed one. The next query will use the new slave connection.

A pool of threads is initialized when using a master/slave configuration. The pool size evolves according to the number of connections.

More information on GitHub here:

| Release Notes | |

Release date: 23 Nov 2015

MariaDB Connector/J 1.3.2 is a (GA) release.

For a list of all changes made in this release, with links to detailed information on each push, see the .

This version is a bugfix release

Notable changes and additions

| Release Notes | |

Release date: 18 Nov 2015

MariaDB Connector/J 1.3.1 is a (GA) release.

For a list of all changes made in this release, with links to detailed information on each push, see the .

This version is a bugfix release

Notable changes and additions

| Release Notes | |

Release date: 8 Dec 2015

MariaDB Connector/J 1.3.3 is a (GA) release.

For a list of all changes made in this release, with links to detailed information on each push, see the .

This version is a bugfix release

Notable changes and additions

Download | Release Notes | Changelog |

Release date: 16 Nov 2015

MariaDB Connector/J 1.3.0 is a Stable (GA) release.

For a list of all changes made in this release, with links to detailed information on each push, see the changelog.

Notable changes and additions

This release includes the following major enhancements :

• Prepared statement on server side.

• Improving memory footprint

• New Date/Time/Timestamps implementation

• New failover options

Prepared statements on server side

A prepared statement is a feature used to execute the same (or similar) SQL statements repeatedly with high efficiency.

This functionality is now executed on the server side.

For example:

When executing connection.prepareStatement the query will be sent to the server. The server will return a statement ID.

When executing executeBatch, only this statement ID will be sent with the query parameter.

This improves performance when many queries are to be executed.

The following new parameters have been added :

The prepared statement will be cached according to the above parameters.

Memory improvement

The memory footprint has been improved for query text and especially for prepared statements.

New Date/Time/Timestamps implementation

A new parameter is added :

There is no change when the parameter useLegacyDatetimeCode is not specified or is true (it is true by default). When this parameter is set tofalse in the JDBC connection string, the new implementation is used. Therefore, the time zone of the server will be used, taking into account the time changes.

Example with a particular timezone:

If Connector/Java is using the "Europe/Paris" timezone, server "Canada/Atlantic" (UTC recommended, but not mandatory).

Using useLegacyDatetimeCode=false or not will return the same result :

The difference will be on the saved data :

with useLegacyDatetimeCode=false:

with useLegacyDatetimeCode=true:

New failover options

AssureReadOnly parameter

A new parameter is added :

When switching host to a slave (by using "connection.setReadOnly(true);" for example), if the database permit it, the connector was always setting the connection in read-only mode, so an Exception will be thrown if a data modification is done on a slave.

To improve performance, this operation will not be performed if the parameter is a assureReadOnly false (default). It's up to you to configure the slaves servers in .

Sequential failover parameter

A new type of failover implementation as been added : Sequential.

This permits failover WITHOUT loadbalancing.

the host will be connected in the order in which they were declared.

Example when using the jdbc url string "jdbc:mysql:replication:host1,host2,host3/test". &#xNAN;When connecting, the driver will always try first host1, and if not available host2 and following. &#xNAN;After a host fail, the driver will reconnect according to this order.

Example :

Connecting order:

• trying to connect to host1. Host1 is up, the driver will use this host.

• host1 fail. The driver will connect to Host2.

• host2 fail. If the host1 is not blacklisted anymore (timeout configure with the loadBalanceBlacklistTimeout parameter) the driver will try to connect to host1, and after host3. If host1 was blacklisted, driver would connect to host3 directly.

Download | Release Notes | Changelog | About MariaDB Connector/J

Release date: 29 Feb 2016

MariaDB Connector/J 1.3.6 is a Stable (GA) release.

For a list of all changes made in this release, with links to detailed information on each push, see the changelog.

This version is a bugfix release.

Notable changes and additions

Major

• : Correction of charset parameter on Statement.setCharacterStream() and setClob

• : Protocol encoding correction for binary field

• : Correction of error in boolean when using scala anorm string interpolation

Minor

• : getBoolean() improvement (for field not normally considered as boolean). TinyInt value >= 2 are now considered as true.

• : Server preparedStatement now used even for query without parameters.

• : multithreading correction on possible race condition on statement.close()