Five transaction isolation levels and seven transaction propagation behaviors in spring

Spring defines these attributes in the transactiondefinition interface.

Five different transaction isolation levels are defined in the transactiondefinition interface.

Isolation_default this is a 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.
Isolation_read_uncommitted: This is the lowest isolation level of the transaction. It allows others to see the uncommitted data of this transaction. This isolation level will generate dirty reads, not repeated reads and Phantom reads

Isolation_read_committed ensures that the data modified by one transaction can be read by another transaction only after it is committed. Another transaction cannot read the uncommitted data of the transaction. This transaction isolation level can avoid dirty reads, but may cause non-repeated reads and Phantom reads.

The transaction isolation level of isolation_repeatable_read can prevent dirty reads and prevent repeated reads. However, phantom reading may occur. In addition to ensuring that one transaction cannot read the uncommitted data of another transaction, it also ensures that the following situations are avoided (non-repeated reads ).

Isolation_serializable this is the most costly but reliable transaction isolation level. Transactions are processed in sequence. In addition to preventing dirty reads and not repeated reads, Phantom reads are also avoided.

The transactiondefinition interface defines seven transaction propagation behaviors.

Propagation_required if a transaction exists, the current transaction is supported. If no transaction exists, a new transaction is started.

Propagation_supports supports the current transaction if there is a transaction. If no transaction exists, the transaction is not executed. However, for the transaction manager for transaction synchronization, propagation_supports is slightly different from not using transactions.

Propagation_mandatory if a transaction already exists, the current transaction is supported. If no active transaction exists, an exception is thrown.

Propagation_requires_new always starts a new transaction. If a transaction already exists, the transaction will be suspended.

Propagation_not_supported always executes non-transactions and suspends any existing transactions.

Propagation_never is always executed in non-transactional mode. If an active transaction exists, an exception is thrown.

Propagation_nested if an active transaction exists, it runs in a nested transaction. If no active transaction exists, it is executed according to the transactiondefinition. propagation_required attribute.