Why mysql JDBC driver returns TRANSACTION_READ_COMMITTED as default isolation level

Question

As I know default transaction isolation level for Mysql DB is REPEATABLE_READ. (see Mysql Transaction Isolation Levels ). But Mysql connector 8 has following code:

public class DatabaseMetaData implements java.sql.DatabaseMetaData {
...
    @Override  
    public int getDefaultTransactionIsolation() throws SQLException {
        return java.sql.Connection.TRANSACTION_READ_COMMITTED;
    }
}

They just ignore default REPEATABLE_READ and set less restricted TRANSACTION_READ_COMMITTED .

It is not clear for me why they did it?

Answer 1

The default for the MySQL Connector/J JDBC driver is not TRANSACTION_REPEATABLE_READ , it is TRANSACTION_READ_COMMITTED as communicated by that DatabaseMetaData implementation. So, although MySQL itself may default to repeatable read when no transaction configuration is specified, the JDBC driver will use read committed as its default when creating transactions.

The choice for TRANSACTION_READ_COMMITTED is likely historical, the previous default engine of MySQL was MyISAM, and this engine does not actually support transactions, so any change was technically immediately committed, and therefor any read would read those new rows. For MyISAM the behaviour matches - largely - TRANSACTION_READ_COMMITTED .

However, we cannot answer with certainty why the developers of MySQL Connector/J really chose this as the default. The JDBC specification itself does not require a specific default, but in my experience, a lot of JDBC drivers use this as the default.