MySql transaction isolation level, Spring transaction propagation

MySql transaction isolation level, Spring transaction management

The data of MySql's default engine InnoDB is stored in a tablespace, which is a black box managed by innoDB and stores a series of data. InnoDB can also put data and indexes for each table into separate files.

InnoDB uses MVCC (MultiVersion  Concurrency  Control) to support high concurrency and implements four standard isolation levels:

transaction level	dirty read	non-repeatable read	hallucinations
READ UNCOMMITTED	Yes	Yes	Yes
READ COMMITTED	no	Yes	Yes
REPEATABLE READ	no	no	Yes
SERIALIZABLE	no	no	no

InnoDB's default level is REPEATABLE READ, and the insertion of phantom rows is prevented by gap locks.

About dirty reads, non-repeatable reads and phantom reads:

Concurrency issues	describe
Dirty Reads	Transaction A reads unpersisted data, such as a data rollback
Non -Repeatable Reads	Transaction A reads the same data multiple times but the results are different
Phantom Reads	Transaction A reads the unified data multiple times but the result is new or missing

 

As another main engine of MySql, the main difference between MyIsam and InnoDB is that the former does not provide support for transactions and row-level locks, and has a serious defect that it cannot be safely recovered after a crash. The inability to support transactions means that the ACID (see the table below) cannot be guaranteed, and the inability to support row-level locks means that only the entire table can be locked, and the performance will drop significantly in a concurrent environment.

Transaction ACID properties:

Atomicity	Transactions are either all done or none of them are done
Consistency	After executing the transaction, the integrity constraints of the database cannot be violated
Isolation	There can be no mutual interference between transactions, and isolation is divided into four levels
Durability	After the transaction ends normally, the data is persisted and cannot be rolled back

 

Transaction management in Spring:

Spring provides the same set of models for JDBC, Hibernate and JTA, all of which are managed through the transaction management interface PlatformTransactionManager, which defines three methods:

public interface PlatformTransactionManager {    
       TransactionStatus getTransaction(TransactionDefinition definition) throws TransactionException;    
       void commit(TransactionStatus status) throws TransactionException;    
       void rollback(TransactionStatus status) throws TransactionException;    
}

Spring transaction features mainly include transaction propagation, transaction level, read-only, timeout, and rollback rules

The default isolation level of the transaction is ISOLATION_DEFAULT, that is, the default isolation level of the database used. The remaining four levels are the same as those described in the above table. It should be noted that Spring itself does not implement a specific implementation of transaction isolation, but relies on the implementation of the database.

 

Transaction propagation, this property defines the transaction context in which a method should run:

propagation properties	describe
PROPAGATION_REQUIRED	Must run in a transaction, if the current transaction does not exist, create a new transaction
PROPAGATION_SUPPORTs	If there is a current transaction, it will run in it, if it does not exist, no transaction is required
PROPAGATION_MANDATORY	Must run in the current transaction, if there is no current transaction, an exception will be thrown
PROPAGATION_REQUIRED_NEW	It must run in its own newly created transaction, which will block the current transaction
PROPAGATION_NOT_SUPPORTed	Must run in a non-transactional environment, will block the current transaction
PROPAGATION_NEVER	Must run in a non-transactional environment, throw an exception if there is a current transaction
PROPAGATION_NESTED	Create a new transaction and nest it into the current transaction, and the outer transaction is rolled back together Rollback, if the external transaction is normal, the internal transaction is completed or rolled back independently

 

Whether the transaction is read-only:

If set to yes, performance will be optimized to some extent

 

Rollback rules:

The default is to roll back after a RuntimeException occurs, but it can also be set to roll back after other exceptions occur

 

Transaction Timeout:

The default value in Spring is 30s. If a timeout occurs, the transaction is rolled back.