1. Characteristics of transactions
Atomicity
Consistency: Once the transaction is completed, the business established by the transaction must be in a consistent state.
Isolation: For many transactions to process the same data, the transactions must be isolated, and the mutual influence between the data cannot be generated.
Persistence: Once the transaction is completed, the state established by the transaction must be retained for a long time and cannot affect each other.
2. What is the basic transaction attribute definition
transaction attribute? Transaction attributes can be understood as some basic configurations of transactions, indicating how transaction attributes are applied to methods.
(1) The first behavior of a transaction is the propagation behavior. When a transaction is invoked by another transaction, it must be specified how the transaction should be propagated. For example, a method can run in an existing transaction or start a new transaction. Spring defines seven propagation behaviors, as follows:
PROPAGATION_REQUIRED: Indicates that the current method must run in a transaction. If the current transaction exists, it will run in the current transaction. If it does not exist, a new transaction will be re-opened.
PROPAGATION_SUPPORTS: Indicates that the current method does not require a transaction context, and runs in the current transaction if the current transaction exists.
PROPAGATION_MANDATORY: Indicates that the current method must run in a transaction, if the transaction does not exist, an exception will be thrown.
PROPAGATION_REQUIRED_NEW: Indicates that the current method must run in its own transaction. If a new transaction will be started. If there is a current transaction, the current transaction will be suspended.
PROPAGATION_NEVER: Indicates that the current method should not run in the error context, if there is a current transaction, an exception will be thrown.
PROPAGATION_NESTED: Indicates that if a thing already exists, the method will run nested in a transaction. Nested transactions can be committed and rolled back independently of the current transaction.
Pay attention to distinguish between PROPAGATION_REQUIRED_NEW and PROPAGATION_NESTED. The former two transactions, the outer transaction and the inner transaction are two independent transactions, that is, the rollback of the inner transaction will not affect the outer transaction, while the rollback of the outer transaction Rolling also does not affect inner transactions. For the latter, the inner transaction is dependent on the outer transaction, that is, the rollback of the inner transaction will not cause the rollback of the outer transaction, and the rollback of the outer transaction will cause the rollback of the inner transaction.
(2) Isolation
level The second level of a transaction is the isolation level, which defines the degree to which a transaction is affected by other concurrent transactions.
Concurrent transactions may usually cause the following problems:
Dirty reads: Dirty reads occur when one transaction reads data that has been rewritten by another transaction but has not yet been committed. At this time, if another transaction rolls back the data, the transaction reads data is invalid.
Non-repeatable read: Non-repeatable read means that a transaction executes the same query more than twice, but the data read before and after is different, that is because in the interval between two reads of data, another transaction Modified.
Phantom reads: Phantom reads are similar to non-repeatable reads. Occurs when one transaction reads several rows of data, and another transaction inserts several rows of data, and subsequent queries will find that the data has changed.
The difference between non-repeatable reads and phantom reads is that non-repeatable reads focus on modification, while joy is in additions and deletions.
The specific isolation levels are as follows:
ISOLATION_DEFAULT: Use the default isolation level of the database backend.
ISOLATION_READ_UNCOMMITED: The lowest isolation level that allows reading uncommitted data changes, which may lead to dirty reads, non-repeatable reads, and phantom reads.
ISOLATION_READ_COMMITED: Allows reading of data changes committed by concurrent transactions, which can prevent dirty reads, but cannot prevent non-repeatable reads and phantom reads.
ISOLATION_REPEATABLE_READ: The result of multiple reads of the same field is the same, unless the transaction itself modifies the data. Dirty reads and non-repeatable reads can be prevented.
ISOLATION_SERIALIZABLE: The highest isolation level, which prevents dirty reads, non-repeatable reads and phantom reads.
(3) The read-only property of a
transaction The third characteristic of a transaction is whether it is a read-only transaction. If the transaction only performs this operation on the back-end database, the database can take advantage of the read-only nature of the transaction to perform some specific optimizations. By making transactions read-only, you give the database a chance to apply optimizations it sees fit.
(4) Transaction timeout
In order for the application to perform well, the transaction cannot run for too long. Because transactions may involve locks on the backend database, long transactions unnecessarily consume data resources. The transaction
timeout is a timer of the transaction. If the transaction is not completed within a certain period of time, it will be automatically rolled back without waiting for its end.
(5) Rollback rules The last set of rules of the
transaction pentagon, these rules define which exceptions will cause the transaction to be rolled back and which will not. By default, the transaction will only be rolled back if it encounters a runtime exception, and will not be rolled back if it encounters a checked exception (this behavior is the same as the EJB rollback behavior),
but you can declare that the transaction Rollback to a specific checked exception as if a runtime exception was encountered. You can also declare that the transaction will not roll on certain exceptions, even if those exceptions are runtime exceptions.
2. Implementing transactions
in SpringBoot It is relatively simple to implement transactions in SpringBoot. The specific examples are as follows:
@Transactional(rollbackFor = {Exception.class}, propagation = Propagation.REQUIRES_NEW,isolation = Isolation.DEFAULT)
@Override
public void addUsers() throws Exception {
for (int i = 0 ;i<10;i++){
User user = new User("test"+i,10+i,"test"+i+"test");
userMapper.addUser(user);
if (i == 11){
throw new Exception();
}
}
}
@Transactional can be applied to classes as well as methods