Spring 事物傳播特性

這是Spring官方的定義 一共有7種 摘自源碼省略了一部分

public interface TransactionDefinition {int PROPAGATION_REQUIRED = 0;int PROPAGATION_SUPPORTS = 1;int PROPAGATION_MANDATORY = 2;int PROPAGATION_REQUIRES_NEW = 3;int PROPAGATION_NOT_SUPPORTED = 4;int PROPAGATION_NEVER = 5;int PROPAGATION_NESTED = 6; } ROPAGATION_REQUIRED -- 支持當前事務，如果當前沒有事務，就新建一個事務。這是最常見的選擇。 PROPAGATION_SUPPORTS -- 支持當前事務，如果當前沒有事務，就以非事務方式執行。 PROPAGATION_MANDATORY -- 支持當前事務，如果當前沒有事務，就拋出異常。 PROPAGATION_REQUIRES_NEW -- 新建事務，如果當前存在事務，把當前事務掛起。 PROPAGATION_NOT_SUPPORTED -- 以非事務方式執行操作，如果當前存在事務，就把當前事務掛起。 PROPAGATION_NEVER -- 以非事務方式執行，如果當前存在事務，則拋出異常。 PROPAGATION_NESTED -- 如果當前存在事務，則在嵌套事務內執行。如果當前沒有事務，則進行與PROPAGATION_REQUIRED類似的操作

前面6個都非常好理解，只有?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.

主要看綠色這段話，大概意思是說?PROPAGATION_NESTED 開始一個 "嵌套的" 事務,? 它是已經存在事務的一個真正的子事務. 潛套事務開始執行時,? 它將取得一個 savepoint. 如果這個嵌套事務失敗, 我們將回滾到此 savepoint. 潛套事務是外部事務的一部分, 只有外部事務結束后它才會被提交.?

說到這大家可能已經清楚這個傳播特性是干啥的了，其實就是利用了數據庫的還原點的原理，底層還是通過設置Connection.setSavepoint() 與數據庫打交道。

ServiceA {/*** 事務屬性配置為 PROPAGATION_REQUIRED*/void methodA() {try {//事務屬性配置為 PROPAGATION_NESTEDServiceB.methodB(); //如果methodB()方法出現異常，則回滾方法B的所有SQL操作} catch (SomeException) {// 執行其他業務, 如 ServiceC.methodC(); }}}

?

轉載一遍文章講解的也很詳細

http://www.iteye.com/topic/35907

總結

以上是生活随笔為你收集整理的Spring 事物传播特性的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。