PROPAGATION_REQUIRED -- 支持當(dāng)前事務(wù)，如果當(dāng)前沒有事務(wù)，就新建一個事務(wù)。這是最常見的選擇。?
PROPAGATION_SUPPORTS -- 支持當(dāng)前事務(wù)，如果當(dāng)前沒有事務(wù)，就以非事務(wù)方式執(zhí)行。?
PROPAGATION_MANDATORY -- 支持當(dāng)前事務(wù)，如果當(dāng)前沒有事務(wù)，就拋出異常。?
PROPAGATION_REQUIRES_NEW -- 新建事務(wù)，如果當(dāng)前存在事務(wù)，把當(dāng)前事務(wù)掛起。?
PROPAGATION_NOT_SUPPORTED -- 以非事務(wù)方式執(zhí)行操作，如果當(dāng)前存在事務(wù)，就把當(dāng)前事務(wù)掛起。?
PROPAGATION_NEVER -- 以非事務(wù)方式執(zhí)行，如果當(dāng)前存在事務(wù)，則拋出異常。?
PROPAGATION_NESTED -- 如果當(dāng)前存在事務(wù)，則在嵌套事務(wù)內(nèi)執(zhí)行。如果當(dāng)前沒有事務(wù)，則進(jìn)行與PROPAGATION_REQUIRED類似的操作。?
前六個策略類似于EJB CMT，第七個（PROPAGATION_NESTED）是Spring所提供的一個特殊變量。?
它要求事務(wù)管理器或者使用JDBC 3.0 Savepoint API提供嵌套事務(wù)行為（如Spring的DataSourceTransactionManager）?

假如有兩個業(yè)務(wù)接口 ServiceA 和 ServiceB, 其中 ServiceA 中有一個方法實(shí)現(xiàn)如下?

/**?
* 事務(wù)屬性配置為 PROPAGATION_REQUIRED?
*/?
void methodA() {?
// 調(diào)用 ServiceB 的方法?
ServiceB.methodB();?
}?

那么如果 ServiceB 的 methodB? 如果配置了事務(wù), 就必須配置為 PROPAGATION_NESTED?

PROPAGATION_REQUIRES_NEW starts a new, independent "inner" transaction for the given scope. This transaction will be committed or rolled back completely independent from the outer transaction, having its own isolation scope, its own set of locks, etc. The outer transaction will get suspended at the beginning of the inner one, and resumed once the inner one has completed.?

Such independent inner transactions are for example used for id generation through manual sequences, where the access to the sequence table should happen in its own transactions, to keep the lock there as short as possible. The goal there is to avoid tying the sequence locks to the (potentially much longer running) outer transaction, with the sequence lock not getting released before completion of the outer transaction.?

PROPAGATION_NESTED on the other hand starts a "nested" transaction, which is a true subtransaction of the existing one. What will happen is that a savepoint will be taken at the start of the nested transaction. íf the nested transaction fails, we will roll back to that savepoint. The nested transaction is part of of the outer transaction, so it will only be committed at the end of of the outer transaction.?

Nested transactions essentially allow to try some execution subpaths as subtransactions: rolling back to the state at the beginning of the failed subpath, continuing with another subpath or with the main execution path there - all within one isolated transaction, and not losing any previous work done within the outer transaction.?

For example, consider parsing a very large input file consisting of account transfer blocks: The entire file should essentially be parsed within one transaction, with one single commit at the end. But if a block fails, its transfers need to be rolled back, writing a failure marker somewhere. You could either start over the entire transaction every time a block fails, remembering which blocks to skip - or you mark each block as a nested transaction, only rolling back that specific set of operations, keeping the previous work of the outer transaction. The latter is of course much more efficient, in particular when a block at the end of the file fails.?

Rolling back the entire transaction is the choice of the demarcation code/config that started the outer transaction.?

So if an inner transaction throws an exception and is supposed to be rolled back (according to the rollback rules), the transaction will get rolled back to the savepoint taken at the start of the inner transaction. The immediate calling code can then decide to catch the exception and proceed down some other path within the outer transaction.?

If the code that called the inner transaction lets the exception propagate up the call chain, the exception will eventually reach the demarcation code of the outer transaction. At that point, the rollback rules of the outer transaction decide whether to trigger a rollback. That would be a rollback of the entire outer transaction then.?

So essentially, it depends on your exception handling. If you catch the exception thrown by the inner transaction, you can proceed down some other path within the outer transaction. If you let the exception propagate up the call chain, it's eventually gonna cause a rollback of the entire outer transaction.?