Transaction Propagation#
Several Scenarios of Transaction Propagation#
| Number | Mechanism | Description | Remarks |
|---|---|---|---|
| 1 | required | If a transaction exists, join it. If no transaction exists, create a new one. This is the most commonly used setting. | Only create one transaction. |
| 2 | requires_new | Always create a new transaction, regardless of whether a transaction exists or not. The old transaction is suspended first, then a new transaction is created. After the new transaction is executed and committed, the old transaction is resumed and finally committed. | 1. Create a new transaction every time. 2. Suspend the old transaction before creating the new transaction. 3. Commit the later executed method first, and commit the earlier executed method later. 4. The rollback of the old transaction does not affect the commit of the new transaction. |
| 3 | nested | If a transaction exists, the nested transaction uses the same transaction as the outer transaction, but with a new savepoint. There are two execution scenarios: (1) If a rollback occurs in the nested transaction, it does not affect the normal commit of the outer transaction. (2) If a rollback occurs in the outer transaction, the nested transaction will also be rolled back. (3) If no exception occurs, the nested transaction and the outer transaction are committed together as a whole. If no transaction exists, perform operations similar to required. | The skin is still there, but the hair is burned. If the skin is gone, where will the hair attach to? |
| 4 | supports | Support the current transaction. If a transaction exists, join it. If no transaction exists, execute it non-transactionally. | Supports does not create a transaction. |
| 5 | not_supported | Do not support transactions. If a transaction exists, suspend the current transaction. If no transaction exists, execute it non-transactionally. | |
| 6 | mandatory | Force, must use a transaction. If a transaction already exists, join it. If no transaction exists, throw an exception. | 1. Mandatory does not create a transaction. 2. The prerequisite for the execution of mandatory is that a transaction already exists. |
| 7 | never | Prohibit transactions. If a transaction exists, throw an exception. If no transaction exists, execute it non-transactionally. | Must be executed in a non-transactional context, otherwise an error will occur. |
Understanding Several Scenarios of Transaction Propagation#
| Behavior | Type |
|---|---|
| Join if exists, ignore if not | supports |
| Always a new transaction, regardless of whether there is an outer transaction or not | requires_new |
| Join if exists, create a new one if not | required |
| Join if exists, add savepoint, create a new one if not | nested |
| No transaction, suspend if there is an outer transaction | not_supported |
| Requires an outer transaction (throws an exception if not satisfied) | mandatory |
| Requires no outer transaction (throws an exception if not satisfied) | mandatory |
Thread Binding (Synchronization Management)#
This article is synchronized and updated to xLog by Mix Space
The original link is https://me.liuyaowen.club/posts/default/Spring