MariaDB Connector/J 1.5.0 Release Notes

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 Aug 2016

MariaDB Connector/J 1.5.0 is a Release candidate (RC) 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

"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


Changelog

For a list of all changes made in this release, with links to detailed information on each push, see the 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.