The so-called transaction propagation behavior means that if a transaction context already exists before starting the current transaction, there are several options to specify the execution behavior of a transactional method. The following constants representing propagation behavior are included in the TransactionDefinition definition:
TransactionDefinition.PROPAGATION_REQUIRED: If a transaction currently exists, join the transaction; if there is no current transaction, create a new transaction.
TransactionDefinition.PROPAGATION_REQUIRES_NEW: Create a new transaction, if there is a current transaction, suspend the current transaction.
TransactionDefinition.PROPAGATION_SUPPORTS: If there is a current transaction, join the transaction; if there is no current transaction, continue to run in a non-transactional manner.
TransactionDefinition.PROPAGATION_NOT_SUPPORTED: run in non-transactional mode, if there is a current transaction, suspend the current transaction.
TransactionDefinition.PROPAGATION_NEVER: Runs in non-transactional mode and throws an exception if a transaction currently exists.
TransactionDefinition.PROPAGATION_MANDATORY: If there is currently a transaction, join the transaction; if there is no current transaction, throw an exception.
TransactionDefinition.PROPAGATION_NESTED: If a transaction currently exists, create a transaction to run as a nested transaction of the current transaction; if there is no current transaction, the value is equivalent to TransactionDefinition.PROPAGATION_REQUIRED.
It should be pointed out here that the previous six transaction propagation behaviors were introduced by Spring from EJB, and they share the same concept. And PROPAGATION_NESTED is Spring-specific. The transaction started with PROPAGATION_NESTED is embedded in the external transaction (if there is an external transaction), at this time, the embedded transaction is not an independent transaction, it depends on the existence of the external transaction, only through the external transaction commit, can the internal transaction be caused Commitment of transactions, nested subtransactions cannot be committed individually. If you are familiar with the concept of savepoints in JDBC, nested transactions are easy to understand. In fact, nested sub-transactions are an application of savepoints. A transaction can include multiple savepoints, and each nested sub-transaction is an application of savepoints. sub-transaction. In addition, the rollback of the outer transaction will also cause the rollback of the nested subtransactions.
引用出处:https://www.nowcoder.com/questionTerminal/1c65d30e47fb4f59a5e5af728218cac4