MariaDB Connector/J 1.5.2 Release Notes

You are viewing an old version of this article. View the current version here.

The most recent Stable (GA) release of MariaDB Connector/J is:
MariaDB Connector/J 3.3.3

Download Release Notes Changelog Connector/J Overview

Release date: 1 Sept 2016

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

For a description of MariaDB Connector/J see the About MariaDB Connector/J page

Notable Changes

This version is a feature release.

Use native SSPI windows implementation

CONJ-295.

kerberos implementation on windows has java limitations. Main limitations are :

  • need a windows registry entry (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters\AllowTGTSessionKey) so windows shared current ticket to java.
  • java kinit must be executed to create a Ticket.
  • restriction when client with local admin rights

See see openJDK issue for more informations

Kerberos GSSAPI implementation on windows in now based on Waffle that support windows SSPI based on JNA.
If waffle-jna (and dependencies) is on classpath, native implementation will automatically be used.

This removes all those limitations.

Support for TLSv1.1 and TLSv1.2

CONJ-249/CONJ-301

Driver before version 1.5 support only TLSv1.
Default supported protocol are now TLSv1 and TLSv1.1, other protocols can be activated by options.

MariaDB and MySQL community server permit TLSv1 and TLSv1.1.
MariaDB server from version 10.0.15 is using the openSSL library permitting TLSv1.2 (>= 5.5.41 for the 5.5 branch). YaSSL doesn't support TLSv1.2, so if MariaDB server is build from sources with YaSSL, only TLSv1 and TLSv1.1 will be available, even for version > 10.0.15

TLSv1.2 can be enabled by setting option enabledSslProtocolSuites to values "TLSv1, TLSv1.1, TLSv1.2".

A new option enabledSslCipherSuites permit to set specific cipher.

New Options :

enabledSslProtocolSuitesForce TLS/SSL protocol to a specific set of TLS versions (comma separated list).
Example : "TLSv1, TLSv1.1, TLSv1.2"
Default: TLSv1, TLSv1.1. Since 1.5.0
enabledSslCipherSuitesForce TLS/SSL cipher (comma separated list).
Example : "TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384"
Default: use JRE ciphers. Since 1.5.0

Performance improvement

CONJ-291

Different performance improvement have been done :

  • Using PreparedStatement on client side use a simple query parser to identify query parameters. This parsing was taking up to 7% of query time, reduced to 3%.
  • Better UTF-8 decoding avoiding memory consumption and gain 1-2% query time for big String.
  • client parsing optimization : rewriteBatchedStatements (insert into ab (i) values (1) and insert into ab (i) values (2) rewritten as insert into ab (i) values (1), (2)) is now 19% faster (Depending on queries 40-50% of CPU time was spend testing that buffer size is big enough to contain query).
  • there was some memory wastage when query return big resultset (> 10kb), slowing query.
  • and a lot more

CONJ-320 Batch improvement : Send X command without reading results, and read those X results asynchronously . Basically that permit to avoid a lot of 'ping-pong' between driver and server.

New Options :

useBatchMultiSendPreparedStatement.executeBatch() will send many QUERY before reading result packets.Default: true. Since 1.5.0
useBatchMultiSendNumberWhen using useBatchMultiSend, indicate maximum query that can be send at a time.
Default: 100. Since 1.5.0

Prepare + execute in one call

CONJ-296

When using MySQL/MariaDB prepared statement, there will be 3 exchanges with server :

  • PREPARE - Prepares statement for execution.
  • EXECUTE - Executes a prepared statement preparing by a PREPARE statement.
  • DEALLOCATE PREPARE - Releases a prepared statement.

See Server prepare documentation for more information.

Since MariaDB 10.2.2, last PREPARE statement id can be identified with value "-1". Driver is using this functionality to PREPARE and EXECUTE in one client-server round-trip.

Client logging

Client logging can be enable, permitting to log query information, execution time and different failover informations. This implementation need the standard SLF4J dependency.

New Options :

logEnable log information. require Slf4j version > 1.4 dependency.
Default: false. Since 1.5.0
maxQuerySizeToLogOnly the first characters corresponding to this options size will be displayed in logs
Default: 1024. Since 1.5.0
slowQueryThresholdNanosWill log query with execution time superior to this value (if defined )
Default: 1024. Since 1.5.0
profileSqllog connection id, query and execution time.
log example :
2016-07-29 23:28:50 [main] INFO org.mariadb.jdbc.MariaDbStatement - Query - conn:10295 - 0,309 ms - "select * from TABLE"
Default: false. Since 1.5.0

Aurora host auto-discovery

(CONJ-325)

Aurora now auto discovers nodes from the cluster endpoint.

Aurora endpoints

Every aurora instance has a specific endpoint, i.e. a URL that identifies the host. These endpoints look like `xxx.yyy.zzz.rds.amazonaws.com`.

There is another endpoint named "cluster endpoint" (format `xxx.cluster-yyy.zzz.rds.amazonaws.com`) which is assigned to the current master instance and will change when a new master is promoted.

In previous versions, cluster endpoint use was discouraged, since, when a failover occurs, this cluster endpoint can point for a limited time to a host that is no longer the current master. Old recommendation was to list all specific end-points, like:

jdbc:mysql:aurora://a.yyy.zzz.rds.amazonaws.com.com,b.yyy.zzz.rds.amazonaws.com.com/db

This kind of URL string will still work, but now the recommended URL string has to use only the cluster endpoint:

jdbc:mysql:aurora://xxx.cluster-yyy.zzz.rds.amazonaws.com/db

The driver will automatically discover master and slaves of this cluster from the current cluster endpoint during connection time. This permits adding new replicas to the cluster instance that will be discovered without changing the driver configuration.

This discovery appends at connection time, so if you are using a pool framework, check if this framework has a property that controls the maximum lifetime of a connection in the pool, and set a value to avoid infinite lifetime. When this lifetime is reached, pool will discarded for the current connection, and will create a new one (if needed). New connections will use the new replicas.

(If connections are never discarded, new replicas will begin to be used only when a failover occurs.)

"LOAD DATA INFILE" Interceptors

CONJ-305 LOAD DATA INFILE The fastest way to load many datas is using query LOAD DATA INFILE.
Problem is using "LOAD DATA LOCAL INFILE" (ie : loading a file from client), may be a security problem :

  • A "man in the middle" proxy server can change the actual file asked from server so client will send a Local file to this proxy.
  • If someone has can execute query from client, he can have access to any file on client (according to the rights of the user running the client process).

See load-data-infile documentation for more information.

Interceptors can now filter LOAD DATA LOCAL INFILE query's file location to validate path / file name. Those interceptors:

  • Must implement interface org.mariadb.jdbc.LocalInfileInterceptor.
  • Use ServiceLoader implementation, so interceptors classes must be listed in file META-INF/services/org.mariadb.jdbc.LocalInfileInterceptor.

Example:

package org.project;
public class LocalInfileInterceptorImpl implements LocalInfileInterceptor {
    @Override
    public boolean validate(String fileName) {
        File file = new File(fileName);
        String absolutePath = file.getAbsolutePath();
        String filePath = absolutePath.substring(0,absolutePath.lastIndexOf(File.separator));
        return filePath.equals("/var/tmp/exchanges");
    }
}

file META-INF/services/org.mariadb.jdbc.LocalInfileInterceptor must exist with content org.project.LocalInfileInterceptorImpl.

You can get ride of defining the META-INF/services file using google auto-service framework, permitting to use annotation @AutoService(LocalInfileInterceptor.class) that will register the implementation as a service automatically.

Using the previous example:

@AutoService(LocalInfileInterceptor.class)
public class LocalInfileInterceptorImpl implements LocalInfileInterceptor {
    @Override
    public boolean validate(String fileName) {
        File file = new File(fileName);
        String absolutePath = file.getAbsolutePath();
        String filePath = absolutePath.substring(0,absolutePath.lastIndexOf(File.separator));
        return filePath.equals("/var/tmp/exchanges");
    }
}

Minor evolution

  • CONJ-260 : Add jdbc nString, nCharacterStream, nClob implementation

Bugfix

  • CONJ-316 : Wrong Exception thrown for ScrollType TYPE_SCROLL_INSENSITIVE
  • CONJ-298 : Error on Callable function exception when no parameter and space before parenthesis
  • CONJ-314 : Permit using Call with Statement / Prepare Statement
  • CONJ-329 and CONJ-330 : rewriteBatchedStatements execute single query exceptions correction.
  • CONJ-331 : clearWarnings() now throw exception on closed connection
  • CONJ-299 : PreparedStatement.setObject(Type.BIT, "1") registered as true.
  • CONJ-293 : permit named pipe connection without host
  • CONJ-333 : ResultSet.getString() of PreparedStatement return NULL When TIME column value=00:00:00

RC corrections

  • CONJ-335 : Pool connection may fail to connect with good user
  • CONJ-332 : option enabledSslCipherSuites rely on java supportedCipherSuites (replacing enabledCipherSuites)
  • UTF-8 conversion correction (last character was not well encode if high surrogate)




Changelog

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


Be notified of new MariaDB Server releases automatically by subscribing to the MariaDB Foundation community announce 'at' lists.mariadb.org announcement list (this is a low traffic, announce-only list). MariaDB plc customers will be notified for all new releases, security issues and critical bug fixes for all MariaDB plc products thanks to the Notification Services.

MariaDB may already be included in your favorite OS distribution. More information can be found on the Distributions which Include MariaDB page.

Comments

Comments loading...
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.