Spring transaction management
what is
A transaction is a logical set of operations that either are performed or none are performed.
In addition, special attention should be paid to whether the transaction can take effect or whether the database engine supports transactions is the key. For example, the commonly used MySQL database uses the InnoDB engine that supports transactions by default. However, if the database engine is changed to myisam, then the program will no longer support transactions!
example
The most classic transaction is often cited as an example of transfer.
If Xiaoming wants to transfer 1,000 yuan to Xiaohong, this transfer will involve two key operations:
Decrease Xiao Ming's balance by 1000 yuan.
Increase Xiaohong's balance by 1000 yuan.
In case a sudden error occurs between these two operations, such as a bank system crash or a network failure, causing Xiaoming's balance to decrease while Xiaohong's balance does not increase, this is wrong. The transaction is to ensure that these two key operations either succeed or fail.
ACID
Do you understand the characteristics of transactions (ACID)?
Atomicity: All operations in a transaction are either completed or not completed, and will not end in a middle link. If an error occurs during the execution of the transaction, it will be rolled back (Rollback) to the state before the transaction started, as if the transaction had never been executed. That is, transactions are indivisible and irreducible.
Consistency: Before the transaction starts and after the transaction ends, the integrity of the database is not violated. This means that written data must fully comply with all preset constraints, triggers, cascading rollbacks, etc.
Isolation: The ability of the database to allow multiple concurrent transactions to read, write and modify its data at the same time. Isolation can prevent data inconsistency caused by cross-execution when multiple transactions are executed concurrently. Transaction isolation is divided into different levels, including uncommitted read (Read uncommitted), committed read (read committed), repeatable read (repeatable read) and serialization (Serializable).
Durability: After the transaction processing ends, the modification to the data is permanent, even if the system fails, it will not be lost.
Two transaction management methods of Spring
Method 1: Programmatic transaction management
Manual transaction management through TransactionTemplate or TransactionManager is rarely used in practical applications, but it is helpful for you to understand the principles of Spring transaction management.
Method 2: Declarative transaction management
is recommended (the code is the least intrusive), and it is actually implemented through AOP (the full annotation method based on @Transactional is used most).
The sample code for transaction management using the @Transactional annotation is as follows:
first look at the Transactional annotation definition
@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface Transactional
What is transaction propagation behavior?
When calling the submethods in the chain, should we use a new transaction or the current transaction? This sub-method decides to use a new transaction or a current transaction (or not use a transaction) strategy, which is called transaction propagation.
In Spring's transaction management, the transaction processing strategy of this submethod is called Propogation Behavior.
But after classifying these communication behaviors, there are nothing more than the following three types:
Use the current transaction first
Do not use the current transaction, create a new transaction
Do not use any transaction
For example:
take Spring JDBC + Spring annotation version of the transaction as an example. Under the default transaction propagation behavior, methodA and methodB will use the same Connection, in a transaction
@Transactional
public void methodA(){
jdbcTemplate.batchUpdate(updateSql, params);
methodB();
}
@Transactional
public void methodB(){
jdbcTemplate.batchUpdate(updateSql, params);
}
What if I want methodB not to use the transaction of methodA, and create a new connection/transaction by myself? Just simply configure the @Transactional annotation:
@Transactional
public void methodA(){
jdbcTemplate.batchUpdate(updateSql, params);
methodB();
}
// 传播行为配置为 - 方式2，不使用当前事务，独立一个新事务
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void methodB(){
jdbcTemplate.batchUpdate(updateSql, params);
}
It's that simple. We don't need to worry about operations such as obtaining Connection/multi-method sharing Connection/multi-method sharing + exclusive Connection/submitting/releasing connection, and Spring has done it for us.
How to roll back?
In the annotated version of transaction management, the default rollback strategy is: rollback when an exception is thrown. This default strategy is very good, even the rollback has been solved for us, and there is no need to manually roll back.
But what if in a nested transaction, the submethod is independent of the new transaction? Even if an exception is thrown at this time, it can only roll back the sub-transaction and cannot directly affect the previous transaction.
However, if the thrown exception is not caused by SQL, such as verification failure or other abnormalities, the current transaction should be rolled back Rollback?
This is not necessarily true. Who said that if an exception is thrown, it will be rolled back, and if the exception is not rolled back, can it work?
sure! Throwing exceptions and rolling back transactions are originally two problems, which can be connected together or handled separately
// 传播行为配置为 - 方式2，不使用当前事务，独立一个新事务
// 指定 Exception 也不会滚
@Transactional(propagation = Propagation.REQUIRES_NEW, noRollbackFor = Exception.class)
public void methodB(){
jdbcTemplate.batchUpdate(updateSql, params);
}
Use different configurations for each transaction/connection
In addition to propagation and rollback, you can also use different configurations for each transaction/connection, such as different isolation levels:
@Transactional
public void methodA(){
jdbcTemplate.batchUpdate(updateSql, params);
methodB();
}
// 传播行为配置为 - 方式2，不使用当前事务，独立一个新事务
// 这个事务/连接中使用 RC 隔离级别，而不是默认的 RR
@Transactional(propagation = Propagation.REQUIRES_NEW, isolation = Isolation.READ_UNCOMMITTED)
public void methodB(){
jdbcTemplate.batchUpdate(updateSql, params);
}
In addition to the isolation level, other JDBC Connection configurations are of course supported, such as readOnly. In this way, although we don't need to display the connection/session, we can still configure different parameters for each transaction in the nest, which is very flexible.
Transaction Manager (TransactionManager) model
There are only two core operations of transaction management: commit and rollback. The so-called propagation, nesting, and rollback mentioned above are all based on these two operations.
Therefore, Spring abstracts the core function of transaction management into a transaction manager (Transaction Manager). Based on the core of the transaction manager, multiple transaction management methods can be implemented.
The core transaction manager has only three functional interfaces:
obtain transaction resources, resources can be arbitrary, such as jdbc connection/hibernate mybatis session, and then bind and store
Commit transaction-commit specified transaction resource
rollback transaction-back Roll the specified transaction resource
interface PlatformTransactionManager{
// 获取事务资源，资源可以是任意的，比如jdbc connection/hibernate mybatis session之类
TransactionStatus getTransaction(TransactionDefinition definition)
throws TransactionException;
// 提交事务
void commit(TransactionStatus status) throws TransactionException;
// 回滚事务
void rollback(TransactionStatus status) throws TransactionException;
}
Transaction Failure Scenario
Spring transaction management
what is
A transaction is a logical set of operations that either are performed or none are performed.
In addition, special attention should be paid to whether the transaction can take effect or whether the database engine supports transactions is the key. For example, the commonly used MySQL database uses the InnoDB engine that supports transactions by default. However, if the database engine is changed to myisam, then the program will no longer support transactions!
example
The most classic transaction is often cited as an example of transfer.
If Xiaoming wants to transfer 1,000 yuan to Xiaohong, this transfer will involve two key operations:
Decrease Xiao Ming's balance by 1000 yuan.
Increase Xiaohong's balance by 1000 yuan.
In case a sudden error occurs between these two operations, such as a bank system crash or a network failure, causing Xiaoming's balance to decrease while Xiaohong's balance does not increase, this is wrong. The transaction is to ensure that these two key operations either succeed or fail.
ACID
Do you understand the characteristics of transactions (ACID)?
Atomicity: All operations in a transaction are either completed or not completed, and will not end in a middle link. If an error occurs during the execution of the transaction, it will be rolled back (Rollback) to the state before the transaction started, as if the transaction had never been executed. That is, transactions are indivisible and irreducible.
Consistency: Before the transaction starts and after the transaction ends, the integrity of the database is not violated. This means that written data must fully comply with all preset constraints, triggers, cascading rollbacks, etc.
Isolation: The ability of the database to allow multiple concurrent transactions to read, write and modify its data at the same time. Isolation can prevent data inconsistency caused by cross-execution when multiple transactions are executed concurrently. Transaction isolation is divided into different levels, including uncommitted read (Read uncommitted), committed read (read committed), repeatable read (repeatable read) and serialization (Serializable).
Durability: After the transaction processing ends, the modification to the data is permanent, even if the system fails, it will not be lost.
Two transaction management methods of Spring
Method 1: Programmatic transaction management
Manual transaction management through TransactionTemplate or TransactionManager is rarely used in practical applications, but it is helpful for you to understand the principles of Spring transaction management.
Method 2: Declarative transaction management
is recommended (the code is the least intrusive), and it is actually implemented through AOP (the full annotation method based on @Transactional is used most).
The sample code for transaction management using the @Transactional annotation is as follows:
first look at the Transactional annotation definition
@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface Transactional
What is transaction propagation behavior?
When calling the submethods in the chain, should we use a new transaction or the current transaction? This sub-method decides to use a new transaction or a current transaction (or not use a transaction) strategy, which is called transaction propagation.
In Spring's transaction management, the transaction processing strategy of this submethod is called Propogation Behavior.
But after classifying these communication behaviors, there are nothing more than the following three types:
Use the current transaction first
Do not use the current transaction, create a new transaction
Do not use any transaction
For example:
take Spring JDBC + Spring annotation version of the transaction as an example. Under the default transaction propagation behavior, methodA and methodB will use the same Connection, in a transaction
@Transactional
public void methodA(){
jdbcTemplate.batchUpdate(updateSql, params);
methodB();
}
@Transactional
public void methodB(){
jdbcTemplate.batchUpdate(updateSql, params);
}
What if I want methodB not to use the transaction of methodA, and create a new connection/transaction by myself? Just simply configure the @Transactional annotation:
@Transactional
public void methodA(){
jdbcTemplate.batchUpdate(updateSql, params);
methodB();
}
// 传播行为配置为 - 方式2，不使用当前事务，独立一个新事务
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void methodB(){
jdbcTemplate.batchUpdate(updateSql, params);
}
It's that simple. We don't need to worry about operations such as obtaining Connection/multi-method sharing Connection/multi-method sharing + exclusive Connection/submitting/releasing connection, and Spring has done it for us.
How to roll back?
In the annotated version of transaction management, the default rollback strategy is: rollback when an exception is thrown. This default strategy is very good, even the rollback has been solved for us, and there is no need to manually roll back.
But what if in a nested transaction, the submethod is independent of the new transaction? Even if an exception is thrown at this time, it can only roll back the sub-transaction and cannot directly affect the previous transaction.
However, if the thrown exception is not caused by SQL, such as verification failure or other abnormalities, the current transaction should be rolled back Rollback?
This is not necessarily true. Who said that if an exception is thrown, it will be rolled back, and if the exception is not rolled back, can it work?
sure! Throwing exceptions and rolling back transactions are originally two problems, which can be connected together or handled separately
// 传播行为配置为 - 方式2，不使用当前事务，独立一个新事务
// 指定 Exception 也不会滚
@Transactional(propagation = Propagation.REQUIRES_NEW, noRollbackFor = Exception.class)
public void methodB(){
jdbcTemplate.batchUpdate(updateSql, params);
}
Use different configurations for each transaction/connection
In addition to propagation and rollback, you can also use different configurations for each transaction/connection, such as different isolation levels:
@Transactional
public void methodA(){
jdbcTemplate.batchUpdate(updateSql, params);
methodB();
}
// 传播行为配置为 - 方式2，不使用当前事务，独立一个新事务
// 这个事务/连接中使用 RC 隔离级别，而不是默认的 RR
@Transactional(propagation = Propagation.REQUIRES_NEW, isolation = Isolation.READ_UNCOMMITTED)
public void methodB(){
jdbcTemplate.batchUpdate(updateSql, params);
}
In addition to the isolation level, other JDBC Connection configurations are of course supported, such as readOnly. In this way, although we don't need to display the connection/session, we can still configure different parameters for each transaction in the nest, which is very flexible.
Transaction Manager (TransactionManager) model
There are only two core operations of transaction management: commit and rollback. The so-called propagation, nesting, and rollback mentioned above are all based on these two operations.
Therefore, Spring abstracts the core function of transaction management into a transaction manager (Transaction Manager). Based on the core of the transaction manager, multiple transaction management methods can be implemented.
The core transaction manager has only three functional interfaces:
obtain transaction resources, resources can be arbitrary, such as jdbc connection/hibernate mybatis session, and then bind and store
Commit transaction-commit specified transaction resource
rollback transaction-back Roll the specified transaction resource
interface PlatformTransactionManager{
// 获取事务资源，资源可以是任意的，比如jdbc connection/hibernate mybatis session之类
TransactionStatus getTransaction(TransactionDefinition definition)
throws TransactionException;
// 提交事务
void commit(TransactionStatus status) throws TransactionException;
// 回滚事务
void rollback(TransactionStatus status) throws TransactionException;
}
Transaction Failure Scenario
