Propagation characteristics and isolation levels of Spring transactions
The so-called transaction propagation behavior is how when multiple transaction methods call each other, how the transaction is propagated among these methods. Spring supports seven transaction propagation behaviors:
Spring's default transaction propagation behavior is PROPAGATION_REQUIRED, which is suitable for most situations. Assuming that ServiveX#methodX() all work in a transactional environment (that is, they are all enhanced by Spring transactions), assuming that the following call chain exists in the program: Service1#method1()->Service2#method2()->Service3#method3() , then the three methods of these three service classes all work in the same transaction through Spring's transaction propagation mechanism.
Several propagation characteristics of transactions
1. PROPAGATION_REQUIRED : If there is a transaction, the current transaction is supported. If there is no transaction, open the default value
2. PROPAGATION_SUPPORTS: If there is a transaction, support the current transaction. If there is no transaction, the non-transactional execution
3. PROPAGATION_MANDATORY: If a transaction already exists, the current transaction is supported. Throws an exception if there is no active transaction.
4. PROPAGATION_REQUIRES_NEW: Always start a new transaction. If a transaction already exists, suspend the existing transaction.
5. PROPAGATION_NOT_SUPPORTED: Always execute non-transactionally and suspend any existing transactions.
6. PROPAGATION_NEVER: Always execute non-transactionally, throw an exception if there is an active transaction
7. PROPAGATION_NESTED: If an active transaction exists, run in a nested transaction. If there is no active transaction, press TransactionDefinition. PROPAGATION_REQUIRED property enforces
Isolation level of Spring transaction
1. ISOLATION_DEFAULT: This is the default isolation level of PlatfromTransactionManager, which uses the default transaction isolation level of the database.
The other four correspond to the isolation level of JDBC
2. ISOLATION_READ_UNCOMMITTED: This is the lowest isolation level of the transaction, which allows another transaction to see the uncommitted data of this transaction. This isolation level produces dirty reads, non-repeatable reads and phantom reads.
3. ISOLATION_READ_COMMITTED: To ensure that the data modified by one transaction can only be read by another transaction after it is committed. Another transaction cannot read the uncommitted data of the transaction
4. ISOLATION_REPEATABLE_READ: This transaction isolation level can prevent dirty reads and non-repeatable reads. However, phantom reads may occur. In addition to ensuring that a transaction cannot read uncommitted data of another transaction, it also ensures that the following situation (non-repeatable read) is avoided.
5. ISOLATION_SERIALIZABLE This is the most expensive but most reliable transaction isolation level. Transactions are processed for sequential execution. In addition to preventing dirty reads, non-repeatable reads, it also avoids phantom reads.
Description of some of the concepts:
Dirty read: refers to when a transaction is accessing data and modifying the data, and the modification has not been submitted to the database, at this time, another transaction also accesses the data, and then uses this data. Because this data is uncommitted data, the data read by another transaction is dirty data, and operations based on dirty data may be incorrect.
Non-repeatable read: Refers to reading the same data multiple times within a transaction. While this transaction is not over, another transaction also accesses the same data. Then, between two reads of data in the first transaction, due to the modification of the second transaction, the data read twice by the first transaction may be different. In this way, the data read twice in a transaction is different, so it is called non-repeatable read.
Illusionary reading: Refers to a phenomenon that occurs when transactions are not executed independently, for example, the first transaction modifies data in a table, and this modification involves all data rows in the table. At the same time, the second transaction also modifies the data in this table by inserting a new row of data into the table. Then, it will happen later that the user who operates the first transaction finds that there are no modified data rows in the table, as if a hallucination occurred.