Spring事務機制主要包括 宣告式事務和程式設計式事務，此處側重講解宣告式事務，程式設計式事務在實際開發中得不到廣泛使用，僅供學習參考。
Spring宣告式事務讓我們從複雜的事務處理中得到解脫。使得我們 再也無需要去處理獲得連線、關閉連線、事務提交和回滾等這些操作。再也無需要我們在與事務相關的方法中處理大量的try…catch…finally程式碼。我們在使用Spring宣告式事務時，有一個非常重要的概念就是事務屬性。事務屬性通常由事務的傳播行為，事務的隔離級別，事務的超時值和事務只讀標誌組成。我們在進行事務劃分時，需要進行事務定義，也就是配置事務的屬性。
下面分別詳細講解，事務的四種屬性，僅供諸位學習參考：
Spring在TransactionDefinition介面中定義這些屬性,以供PlatfromTransactionManager使用, PlatfromTransactionManager是Spring事務管理的核心介面。
public interface TransactionDefinition {
int getPropagationBehavior(); //返回事務的傳播行為。
int getIsolationLevel(); //返回事務的隔離級別，事務管理器根據它來控制另外一個事務可以看到本事務內的哪些資料。
int getTimeout(); //返回事務必須在多少秒內完成。
boolean isReadOnly(); //事務是否只讀，事務管理器能夠根據這個返回值進行優化，確保事務是隻讀的。
}
複製程式碼- TransactionDefinition介面中定義五個隔離級別：
ISOLATION_DEFAULT 這是一個PlatfromTransactionManager預設的隔離級別，使用資料庫預設的事務隔離級別.另外四個與JDBC的隔離級別相對應；
ISOLATION_READ_UNCOMMITTED 這是事務最低的隔離級別，它充許別外一個事務可以看到這個事務未提交的資料。這種隔離級別會產生髒讀，不可重複讀和幻像讀。
ISOLATION_READ_COMMITTED 保證一個事務修改的資料提交後才能被另外一個事務讀取。另外一個事務不能讀取該事務未提交的資料。這種事務隔離級別可以避免髒讀出現，但是可能會出現不可重複讀和幻像讀。
ISOLATION_REPEATABLE_READ 這種事務隔離級別可以防止髒讀，不可重複讀。但是可能出現幻像讀。它除了保證一個事務不能讀取另一個事務未提交的資料外，還保證了避免下面的情況產生(不可重複讀)。
ISOLATION_SERIALIZABLE 這是花費最高代價但是最可靠的事務隔離級別。事務被處理為順序執行。除了防止髒讀，不可重複讀外，還避免了幻像讀。
- 在TransactionDefinition介面中定義了七個事務傳播行為：
（1）PROPAGATION_REQUIRED 如果存在一個事務，則支援當前事務。如果沒有事務則開啟一個新的事務。
// 事務屬性 PROPAGATION_REQUIRED
methodA {
……
methodB();
……
}
// 事務屬性 PROPAGATION_REQUIRED
methodB {
……
}
複製程式碼使用Spring宣告式事務，spring使用AOP來支援宣告式事務，會根據事務屬性，自動在方法呼叫之前決定是否開啟一個事務，並在方法執行之後決定事務提交或回滾事務。
單獨呼叫methodB方法：
main {
metodB();
}
相當於
Main {
Connection con=null;
try{
con = getConnection();
con.setAutoCommit(false);
//方法呼叫
methodB();
//提交事務
con.commit();
} Catch(RuntimeException ex) {
//回滾事務
con.rollback();
} finally {
//釋放資源
closeCon();
}
}
複製程式碼Spring保證在methodB方法中所有的呼叫都獲得到一個相同的連線。在呼叫methodB時，沒有一個存在的事務，所以獲得一個新的連線，開啟了一個新的事務。
單獨呼叫MethodA時，在MethodA內又會呼叫MethodB。執行效果相當於：
Main {
Connection con = null;
try {
con = getConnection();
methodA();
con.commit();
} catch(RuntimeException ex) {
con.rollback();
} finally {
closeCon();
}
}
複製程式碼呼叫MethodA時，環境中沒有事務，所以開啟一個新的事務.當在MethodA中呼叫MethodB時，環境中已經有了一個事務，所以methodB就加入當前事務。
（2）PROPAGATION_SUPPORTS 如果存在一個事務，支援當前事務。如果沒有事務，則非事務的執行。但是對於事務同步的事務管理器，PROPAGATION_SUPPORTS與不使用事務有少許不同。
// 事務屬性 PROPAGATION_REQUIRED
methodA() {
methodB();
}
// 事務屬性 PROPAGATION_SUPPORTS
methodB() {
……
}
複製程式碼單純的呼叫methodB時，methodB方法是非事務的執行的。當呼叫methdA時,methodB則加入了methodA的事務中執行。
（3）PROPAGATION_MANDATORY 如果已經存在一個事務，支援當前事務。如果沒有一個活動的事務，則丟擲異常。
// 事務屬性 PROPAGATION_REQUIRED
methodA() {
methodB();
}
//事務屬性 PROPAGATION_MANDATORY
methodB() {
……
}
複製程式碼當單獨呼叫methodB時，因為當前沒有一個活動的事務，則會丟擲異常throw new IllegalTransactionStateException("Transaction propagation 'mandatory' but no existing transaction found"); 當呼叫methodA時，methodB則加入到methodA的事務中執行。
（4）PROPAGATION_REQUIRES_NEW 總是開啟一個新的事務。如果一個事務已經存在，則將這個存在的事務掛起。
//事務屬性 PROPAGATION_REQUIRED
methodA() {
doSomeThingA();
methodB();
doSomeThingB();
}
//事務屬性 PROPAGATION_REQUIRES_NEW
methodB() {
……
}
複製程式碼main() {
methodA();
}
複製程式碼相當於：
main() {
TransactionManager tm = null;
try {
// 獲得一個JTA事務管理器
tm = getTransactionManager();
tm.begin();
// 開啟一個新的事務
Transaction ts1 = tm.getTransaction();
doSomeThing();
tm.suspend(); // 掛起當前事務
try {
tm.begin();// 重新開啟第二個事務
Transaction ts2 = tm.getTransaction();
methodB();
ts2.commit();// 提交第二個事務
} catch(RunTimeException ex) {
ts2.rollback(); // 回滾第二個事務
} finally {
// 釋放資源
}
// methodB執行完後，復恢第一個事務
tm.resume(ts1);
doSomeThingB();
ts1.commit();// 提交第一個事務
} catch(RunTimeException ex) {
ts1.rollback();// 回滾第一個事務
} finally {
//釋放資源
}
}
複製程式碼在這裡，我把 ts1稱為外層事務，ts2稱為內層事務。從上面的程式碼可以看出，ts2與ts1是兩個獨立的事務，互不相干。Ts2是否成功並不依賴於ts1。如果methodA方法在呼叫methodB方法後的doSomeThingB方法失敗了，而methodB方法所做的結果依然被提交。而除了methodB之外的其它程式碼導致的結果卻被回滾了。使用PROPAGATION_REQUIRES_NEW,需要使用JtaTransactionManager作為事務管理器。
（5）PROPAGATION_NOT_SUPPORTED 總是非事務地執行，並掛起任何存在的事務。使用PROPAGATION_NOT_SUPPORTED,也需要使用JtaTransactionManager作為事務管理器。
（6）PROPAGATION_NEVER 總是非事務地執行，如果存在一個活動事務，則丟擲異常；
（7）PROPAGATION_NESTED如果一個活動的事務存在，則執行在一個巢狀的事務中. 如果沒有活動事務, 則按TransactionDefinition.PROPAGATION_REQUIRED 屬性執行。這是一個巢狀事務,使用JDBC 3.0驅動時,僅僅支援DataSourceTransactionManager作為事務管理器。需要JDBC 驅動的java.sql.Savepoint類。有一些J他的事務管理器實現可能也提供了同樣的功能。使用PROPAGATION_NESTED，還需要把PlatformTransactionManager的nestedTransactionAllowed屬性設為true;而nestedTransactionAllowed屬性值預設為false;
// 事務屬性 PROPAGATION_REQUIRED
methodA() {
doSomeThingA();
methodB();
doSomeThingB();
}
//事務屬性 PROPAGATION_NESTED
methodB() {
……
}
複製程式碼如果單獨呼叫methodB方法，則按REQUIRED屬性執行。如果呼叫methodA方法，相當於下面的效果：
main() {
Connection con = null;
Savepoint savepoint = null;
try{
con = getConnection();
con.setAutoCommit(false);
doSomeThingA();
savepoint = con2.setSavepoint();
try{
methodB();
} catch(RuntimeException ex) {
con.rollback(savepoint);
} finally {
//釋放資源
}
doSomeThingB();
con.commit();
} catch(RuntimeException ex) {
con.rollback();
} finally {
//釋放資源
}
}
複製程式碼當methodB方法呼叫之前，呼叫setSavepoint方法，儲存當前的狀態到savepoint。如果methodB方法呼叫失敗，則恢復到之前儲存的狀態。但是需要注意的是，這時的事務並沒有進行提交，如果後續的程式碼(doSomeThingB()方法)呼叫失敗，則回滾包括methodB方法的所有操作。
巢狀事務一個非常重要的概念就是內層事務依賴於外層事務。外層事務失敗時，會回滾內層事務所做的動作。而內層事務操作失敗並不會引起外層事務的回滾。
PROPAGATION_NESTED 與PROPAGATION_REQUIRES_NEW的區別:
它們非常類似,都像一個巢狀事務，如果不存在一個活動的事務，都會開啟一個新的事務。
使用PROPAGATION_REQUIRES_NEW時，內層事務與外層事務就像兩個獨立的事務一樣，一旦內層事務進行了提交後，外層事務不能對其進行回滾。兩個事務互不影響。兩個事務不是一個真正的巢狀事務。同時它需要JTA事務管理器的支援。使用PROPAGATION_NESTED時，
外層事務的回滾可以引起內層事務的回滾。而內層事務的異常並不會導致外層事務的回滾，它是一個真正的巢狀事務。DataSourceTransactionManager使用savepoint支援PROPAGATION_NESTED時，需要JDBC 3.0以上驅動及1.4以上的JDK版本支援。其它的JTA TrasactionManager實現可能有不同的支援方式。
PROPAGATION_REQUIRES_NEW 啟動一個新的, 不依賴於環境的 "內部" 事務。這個事務將被完全 commited 或 rolled back 而不依賴於外部事務, 它擁有自己的隔離範圍, 自己的鎖, 等等. 當內部事務開始執行時, 外部事務將被掛起, 內務事務結束時, 外部事務將繼續執行。另一方面, PROPAGATION_NESTED 開始一個 "巢狀的" 事務, 它是已經存在事務的一個真正的子事務.
潛套事務開始執行時, 它將取得一個 savepoint. 如果這個巢狀事務失敗, 我們將回滾到此 savepoint. 潛套事務是外部事務的一部分, 只有外部事務結束後它才會被提交。由此可見, PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED 的最大區別在於,
PROPAGATION_REQUIRES_NEW 完全是一個新的事務, 而 PROPAGATION_NESTED 則是外部事務的子事務, 如果外部事務 commit, 潛套事務也會被 commit, 這個規則同樣適用於 roll back。PROPAGATION_REQUIRED應該是我們首先的事務傳播行為。它能夠滿足我們大多數的事務需求。