MariaDB Connector/J 1.3.0 Release notes
Download Release Notes Changelog Connector/J Overview
Beta Release date: 29 Sep 2015
MariaDB Connector/J 1.3.0 is a Beta release.
For a description of the MariaDB Connector/J see the About the MariaDB Connector/J page.
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 statement on server side
A prepared statement is a feature used to execute the same (or similar) SQL statements repeatedly with high efficiency.
This functionnality is now executed on server side.
Example with :
PreparedStatement pst = connection.prepareStatement("INSERT INTO exemple VALUES (?)");
int i=1000;
while(i>0) {
pst.setInt(1, i--);
pst.addBatch();
}
pst.executeBatch();
When executing "connection.prepareStatement" the query will be send to server. Server will return an statement ID. When executing "executeBatch", only this statement Id will be send with the query parameter.
This improve performance if many query are to be executed.
new parameters are added :
| cachePrepStmts | enable/disable prepare Statement cache default to true |
|---|---|
| prepStmtCacheSize | This sets the number of prepared statements that the driver will cache per VM if "cachePrepStmts" is enabled. default to 250 |
| prepStmtCacheSqlLimit | This is the maximum length of a prepared SQL statement that the driver will cache if "cachePrepStmts" is enabled. default to 2048 |
The prepared statement will be cached according to those parameters.
Memory improvement
The memory footprint has been improved for queries texts and especially for prepared statements.
New Date/Time/Timestamps implementation
A new parameter is added :
| useLegacyDatetimeCode | if false (recommended if new database), use serverTime zone when storing Datetime/Timestamps default to true |
|---|
There is no change when the parameter "useLegacyDatetimeCode" is not specified or is true (true by default). When this parameter is set to false 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.
Exemple with some particular timezone:
| UTC TIME | PARIS TIME | CANADA TIME |
|---|---|---|
| 2015- 2- 29T00:45:00+0000 | 2015- 2- 29T01:45:00+1000 | 2015- 2- 28 21:45:00-3000 |
| 2015- 2- 29T01:15:00+0000 | 2015- 2- 29T03:15:00+2000 | 2015- 2- 28 22:15:00-3000 |
If Java client is using "Europe/Paris" timezone, server "Canada/Atlantic" (UTC recommended, but not mandatory).
TimeZone.setDefault(TimeZone.getTimeZone("Europe/Paris"));
connection.createStatement().execute("CREATE TABLE daylight (t1 TIMESTAMP(6), t2 DATETIME(6))");
PreparedStatement pst = connection.prepareStatement("INSERT INTO daylight VALUES (?, ?)");
pst.setTimestamp(1, Timestamp.valueOf("2015-03-29 01:45:00"));
pst.setTimestamp(2, Timestamp.valueOf("2015-03-29 03:15:00"));
...
Using useLegacyDatetimeCode=false or not will return the same result :
ResultSet res = connection.createStatement().executeQuery("SELECT * FROM daylight");
res.next();
assertEquals(res.getTimestamp(1),Timestamp.valueOf("2015-03-29 01:45:00"));
assertEquals(res.getTimestamp(2),Timestamp.valueOf("2015-03-29 01:45:00"));
res.next();
assertEquals(res.getTimestamp(1),Timestamp.valueOf("2015-03-29 03:15:00"));
assertEquals(res.getTimestamp(2),Timestamp.valueOf("2015-03-29 03:15:00"));
The difference will be on the saved data :
with useLegacyDatetimeCode=false:
| t1 | t2 |
|---|---|
| 2015-03-28 21:45:00.000000 | 2015-03-28 22:15:00.000000 |
with useLegacyDatetimeCode=false:
| t1 | t2 |
|---|---|
| 2015-03-29 01:45:00.000000 | 2015-03-29 03:15:00.000000 |
New failover options
AssureReadOnly parameter
A new parameter is added :
| assureReadOnly | If true, in high availalability, and switching to a read-only host, assure that this host is in read-only mode by setting session read-only. default to false |
|---|
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 read_only mode.
Sequencial failover parameter
A new type of failover implementation as been added : Sequential.
This permit 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".
When connecting, the driver will always try first host1, and if not available host2 and following.
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.
