MySQL Connector/J Release Notes
-
If 'cacheCallableStmts' is enabled, how many callable statements should be cached?
Default Value 100 Since Version 3.1.2 -
The number of queries to cache 'ResultSetMetadata' for if 'cacheResultSetMetaData' is set to "true".
Default Value 50 Since Version 3.1.1 -
Should the driver refer to the internal values of auto-commit and transaction isolation that are set by 'Connection.setAutoCommit()' and 'Connection.setTransactionIsolation()' and transaction state as maintained by the protocol, rather than querying the database or blindly sending commands to the database for 'commit()' or 'rollback()' method calls?
Default Value false Since Version 3.1.7 -
Should the driver use the in-transaction state provided by the MySQL protocol to determine if a 'commit()' or 'rollback()' should actually be sent to the database?
Default Value false Since Version 5.1.7 -
If prepared statement caching is enabled, how many prepared statements should be cached?
Default Value 25 Since Version 3.0.10 -
If prepared statement caching is enabled, what's the largest SQL the driver will cache the parsing for?
Default Value 256 Since Version 3.0.10 -
Name of a class implementing 'com.mysql.cj.CacheAdapterFactory', which will be used to create caches for the parsed representation of prepared statements. Prior to version 8.0.29, this property was named 'parseInfoCacheFactory', which remains as an alias.
Default Value com.mysql.cj.PerConnectionLRUFactory Since Version 5.1.1 -
Name of a class implementing 'com.mysql.cj.CacheAdapterFactory', which will be used to create caches for MySQL server configuration values.
Default Value com.mysql.cj.util.PerVmServerConfigCacheFactory Since Version 5.1.1 -
Should the driver always communicate with the database when 'Connection.setTransactionIsolation()' is called? If set to "false", the driver will only communicate with the database when the requested transaction isolation is different than the whichever is newer, the last value that was set via 'Connection.setTransactionIsolation()', or the value that was read from the server when the connection was established. Note that "useLocalSessionState=true" will force the same behavior as "alwaysSendSetIsolation=false", regardless of how 'alwaysSendSetIsolation' is set.
Default Value true Since Version 3.1.7 -
Should the driver maintain various internal timers to enable idle time calculations as well as more verbose error messages when the connection to the server fails? Setting this property to false removes at least two calls to 'System.getCurrentTimeMillis()' per query.
Default Value true Since Version 3.1.9 -
Should the driver use cursor-based fetching to retrieve rows? If set to "true" and 'defaultFetchSize' is set to a value higher than zero or 'setFetchSize()' with a value higher than zero is called on a statement, then the cursor-based result set will be used. Please note that 'useServerPrepStmts' is automatically set to "true" in this case because cursor functionality is available only for server-side prepared statements.
Default Value false Since Version 5.0.0 -
Should the driver cache the parsing stage of CallableStatements?
Default Value false Since Version 3.1.2 -
Should the driver cache the parsing stage of PreparedStatements of client-side prepared statements, the "check" for suitability of server-side prepared and server-side prepared statements themselves?
Default Value false Since Version 3.0.10 -
Should the driver cache 'ResultSetMetaData' for statements and prepared statements?
Default Value false Since Version 3.1.1 -
Should the driver cache the results of "SHOW VARIABLES" and "SHOW COLLATION" on a per-URL basis?
Default Value false Since Version 3.1.5 -
The driver will call 'setFetchSize(n)' with this value on all newly-created statements.
Default Value 0 Since Version 3.1.9 -
dontCheckOnDuplicateKeyUpdateInSQLStops checking if every INSERT statement contains the "ON DUPLICATE KEY UPDATE" clause. As a side effect, obtaining the statement's generated keys information will return a list where normally it would not. Also be aware that, in this case, the list of generated keys returned may not be accurate. The effect of this property is canceled if set simultaneously with "rewriteBatchedStatements=true".
Default Value false Since Version 5.1.32 -
Should the driver only issue 'set autocommit=n' queries when the server's state doesn't match the requested state by 'Connection.setAutoCommit(boolean)'?
Default Value false Since Version 3.1.3 -
Sets the default escape processing behavior for Statement objects. The method 'Statement.setEscapeProcessing()' can be used to specify the escape processing behavior for an individual statement object. Default escape processing behavior in prepared statements must be defined with the property 'processEscapeCodesForPrepStmts'.
Default Value true Since Version 6.0.1 -
When enabled, query timeouts set via 'Statement.setQueryTimeout()' use a shared 'java.util.Timer' instance for scheduling. Even if the timeout doesn't expire before the query is processed, there will be memory used by the 'TimerTask' for the given timeout which won't be reclaimed until the time the timeout would have expired if it hadn't been cancelled by the driver. High-load environments might want to consider disabling this functionality.
Default Value true Since Version 5.0.6 -
What size result set row should the JDBC driver consider large, and thus use a more memory-efficient way of representing the row internally?
Default Value 2048 Since Version 5.1.1 -
Should the driver issue appropriate statements to implicitly set the transaction access mode on server side when 'Connection.setReadOnly()' is called? Setting this property to "true" enables InnoDB read-only potential optimizations but also requires an extra roundtrip to set the right transaction state. Even if this property is set to "false", the driver will do its best effort to prevent the execution of database-state-changing queries.
Default Value true Since Version 5.1.35 -
Should the driver use multi-queries, regardless of the setting of 'allowMultiQueries', as well as rewriting of prepared statements for INSERT and REPLACE queries into multi-values clause statements when 'executeBatch()' is called?
Notice that this might allow SQL injection when using plain statements and the provided input is not properly sanitized. Also notice that for prepared statements, if the stream length is not specified when using 'PreparedStatement.set*Stream()', the driver would not be able to determine the optimum number of parameters per batch and might return an error saying that the resultant packet is too large.
'Statement.getGeneratedKeys()', for statements that are rewritten only works when the entire batch consists of INSERT or REPLACE statements.
Be aware that when using "rewriteBatchedStatements=true" with "INSERT ... ON DUPLICATE KEY UPDATE" for rewritten statements, the server returns only one value for all affected (or found) rows in the batch, and it is not possible to map it correctly to the initial statements; in this case the driver returns "0" as the result for each batch statement if total count was zero, and 'Statement.SUCCESS_NO_INFO' if total count was above zero.
Default Value false Since Version 3.1.13 -
Use optimized non-blocking buffered input stream when reading from the server?
Default Value true Since Version 3.1.5