Spring transaction isolation level and propagation characteristics

In spring, declarative transactions are defined by transaction parameters. A transaction parameter is a description of how a transaction policy should be applied to a method, as shown in a total of 5 aspects of a transaction parameter:

Propagation behavior

The first aspect of a transaction is the propagation behavior. The propagation behavior defines the transaction boundary about the client and the called method. Spring defines the propagation behavior in 7.

propagation Behavior	meaning
Propagation_mandatory	Indicates that the method must be running in a transaction. If no transaction is currently occurring, an exception will be thrown
propagation_nested	Indicates that if a transaction is currently in progress, the method should run in a nested transaction. A nested transaction can be committed or rolled back independently of the encapsulated transaction. If the encapsulated transaction does not exist, the behavior is like propagation_requires.
Propagation_never	Indicates that the current method should not run in a transaction. If a transaction is in progress, an exception is thrown.
propagation_not_supported	Indicates that the method should not run in a transaction. If an existing transaction is in progress, it will be suspended during the operation of the method.
Propagation_supports	Indicates that the current method does not require a transactional context, but it can also run in this transaction if a transaction is already running.
Propagation_requires_new	Indicates that the current method must run in its own transaction. A new transaction will be started, and if an existing transaction is running, it will be suspended while the method is running.
Propagation_requires	Indicates that the current method must run in a transaction. If an existing transaction is in progress, the method runs in that transaction, or a new transaction is started.

The propagation rule answers the question whether a new transaction should be started or suspended, or if a method should run in a transactional context.

Isolation level

The second aspect of a declarative transaction is the isolation level. The isolation level defines the degree to which a transaction may be affected by other concurrent transaction activity activities. Another way to think about the isolation level of a transaction is to think of it as the selfish degree to which the transaction deals with the data.

In a typical application, multiple transactions run concurrently, often manipulating the same data to complete their work. Concurrency, though required, can cause problems:

• Dirty Reads (Dirty read)--dirty reads occur when a transaction reads data that has been overwritten by another transaction but has not yet been committed. If these changes are rolled back later, the data read by the first transaction will be invalid.
• Non-repeatable read (nonrepeatable Read)-non-repeatable reads occur when a transaction executes the same query two or more times, but each query result is not the same. This is usually due to the fact that another concurrent transaction has updated data between two queries.
• Phantom reads (Phantom reads)-Phantom reads and non-repeatable reads are similar. Phantom reads occur when a transaction (T1) reads several rows of records and another concurrent transaction (T2) inserts some records. In subsequent queries, the first transaction (T1) will find some additional records that were not originally available.

In an ideal state, transactions are completely isolated from each other, preventing these problems from occurring. However, full isolation can affect performance because isolation often involves locking records in the database (and sometimes locking the complete data table). An aggressive lock can hinder concurrency and require transactions to wait for each other to complete the work.

Given that full isolation affects performance, and not all applications require complete isolation, there are times when transaction isolation can be handled flexibly. Therefore, there will be several isolation levels.

Isolation Level	meaning
Isolation_default	Use the default isolation level of the back-end database.
isolation_read_uncommitted	Allows you to read changes that have not yet been committed. May cause dirty reads, Phantom reads, or non-repeatable reads.
isolation_read_committed	Allows reading from a concurrent transaction that has already been committed. Can prevent dirty reads, but Phantom reads and non-repeatable reads may still occur.
Isolation_repeatable_read	The result of multiple reads of the same field is consistent unless the data is changed by the current transaction itself. can prevent dirty reads and non-repeatable reads, but Phantom reads can still occur.
Isolation_serializable	Completely obey the isolation level of acid, ensuring that no dirty reads, non-repeatable reads, and phantom reads occur. This is also the slowest in all isolation levels, as it is usually done by completely locking the data tables involved in the current transaction.

Read-only

The third attribute of a declarative transaction is whether it is a read-only transaction. If a transaction performs only read operations on the back-end database, the database may take advantage of the read-only feature of that transaction, taking some optimizations. By declaring a transaction as read-only, you can give the backend database an opportunity to apply the optimizations that it deems appropriate. Because read-only optimizations are implemented by a back-end database when a transaction is started, only the propagation behavior that has the potential to start a new transaction (Propagation_requires_new, propagation_required, ropagation _nested) method, it makes sense to declare a transaction as read-only.

In addition, if Hibernate is used as a persistence mechanism, then declaring a transaction as read-only will make Hibernate's flush mode set to Flush_never. This tells hibernate to avoid unnecessary object synchronization with the database, thus delaying all updates to the end of the transaction.

Transaction timeout

In order for an application to perform well, its transactions cannot run for too long. Therefore, the next attribute of a declarative transaction is its timeout.

Assuming that the transaction runs for a very long time, the long-running transaction unnecessarily consumes the database resources because the transaction may involve locking the backend database. You can then declare that a transaction automatically rolls back after a certain number of seconds, without waiting for it to end itself.

Because the timeout clock begins when a transaction starts, only the propagation behavior that has the potential to start a new transaction (Propagation_requires_new, propagation_required, Ropagation_ NESTED), declaring a transaction timeout makes sense.

Rolling back rules

The next edge of a transaction Pentagon is a set of rules that define which exceptions cause rollback and which do not. By default, transactions are rolled back only when there is a runtime exception (runtime exception), and are not rolled back when a check exception (checked exception) occurs (this behavior is consistent with the rollback behavior in the EJB).

However, you can also declare a rollback as a run-time exception when a particular checked exception occurs. Similarly, you can declare that a transaction does not roll back when a particular exception occurs, even if those exceptions are run-time.

Extended Reading

The title is the isolation level of the transaction and the propagation mechanism, but incidentally this tells the five attributes of the declarative transaction. ：）

The article begins by saying that the source of the transaction in spring is checked to see if the propagation mechanism for the 3.0 and later transactions is reduced, in fact, the isolation level of the transaction, the propagation mechanism, the read-only, and all the information about the timeout are defined in the Transactiondefinition interface. The source code is as follows, the interest can compare with oneself, look English comment.

Spring transaction isolation level and propagation characteristics