要想瞭解Spring的事務，首先要瞭解資料庫事務的基本知識，資料庫併發會產生很多問題，Spring使用ThreadLocal技術來處理這些問題，那麼我們必須瞭解Java的ThreadLocal技術。下麵我們逐一瞭解。 第一回合：資料庫事務的基本知識 什麼是資料庫事務？ 一次執行多個SQL語句，全部執 ...
要想瞭解Spring的事務，首先要瞭解資料庫事務的基本知識，資料庫併發會產生很多問題，Spring使用ThreadLocal技術來處理這些問題，那麼我們必須瞭解Java的ThreadLocal技術。下麵我們逐一瞭解。
第一回合：資料庫事務的基本知識
什麼是資料庫事務？
一次執行多個SQL語句，全部執行成功則成功，有一個執行失敗則全部失敗。即“一榮俱榮，一損俱損”。
資料庫的事務必須同時滿足下列四個條件：
l 原子性（Atomic）：比如資料庫一次執行四個SQL語句，那麼這四個SQL就是巨集觀的一個不可分割單元，“一榮俱榮，一損俱損”。全部執行成功則成功，有一個執行失敗則全部失敗。三分歸元氣。
l 一致性（Consistency）：整個事務不管成功了還是失敗了，整個資料庫的狀態和規則不能變化。即：A賬戶轉賬100元到B賬戶，這個事務過程結束後前後，資料庫中總的賬戶金額是不變的。
l 隔離性（Isolation）：不同的事務併發執行時，各自擁有不同的數據空間，你走你的陽關道，我走我的獨木橋，互不幹擾。
但並非完全不幹擾，資料庫規定了事務隔離級別，隔離級別越高，數據的一致性越好，併發性越弱。
l 持久性（Durability）：一旦事務提交成功，事務中的所有數據操作都必須被持久化到資料庫中。
這樣一來，即使剛提交完，資料庫就崩潰，當重啟資料庫之後，也可以根據已經保存（持久化）的操作來恢複數據。
一致性是結果，其他三個是手段。
- 資料庫管理一般採用重執行日誌保證原子性、一致性和持久性。
- 重執行日誌記錄了資料庫變化的每一個動作。這樣，即使資料庫事務在執行了一部分操作後發生錯誤退出，可以根據重執行日誌來撤銷已經執行的操作。
- 對於已經提交的事務，即使資料庫崩潰，再重啟資料庫時也能夠根據日誌對尚未持久化的數據進行相應的重執行操作。
- 資料庫管理系統採用資料庫鎖機制來保證事務的隔離性（正如Java採用對象鎖機制進行線程同步。）
數據併發的問題
多個客戶端同時操作一個資料庫，該併發過程就可能引起併發問題：
l 臟讀(dirty read)：A事務讀取B事務尚未提交的數據併進行一系列操作，結果B事務執行了回滾，那麼這時，A事務讀到的數據就是不被認可的，是臟數據。
l 不可重覆讀(unrepeatable read):比如：A開始了查詢事務，B開始了提款事務。A第一次查詢餘額為1000元，這時B提取100元，A第二次查詢餘額時，變成了900元，與第一次查詢的餘額不同。
l 幻象讀（phantom read）：一般發生在計算統計數據的事務中。比如；銀行正在統計所有賬戶的存款總額，統計出來為10000元。這時正好新增了一個賬戶，存款1000元。再次統計發現總額為11000元，與前一次統計不同。
不可重覆讀是指讀到了更改的數據（一般情況下需要添加行級鎖，阻止操作中的數據變化），而幻象讀是指讀到了新增的數據（往往需要添加表級鎖，將整個表鎖定）。
l 第一類丟失更新：目前賬戶餘額1000元，A開始事務-->B開始事務-->B匯入100元，餘額改為1100元-->B提交事務àA取出100元，把餘額改為900元-->A撤銷事務-->餘額恢復為1000元（丟失更新）。
A事務撤銷時，把B提交的更新數據給覆蓋了。
l 第二類丟失更新：B開始事務-->A開始事務-->B查詢餘額為1000元-->A查詢餘額為1000元-->B取出100元，把餘額改為900元-->B提交事務-->A匯入100元-->A提交事務-->A把餘額改為1100元（丟失更新）。
A在提交事務時，把B所做的操作丟失。
JDBC對事務的支持
Connection預設情況下是自動提交的。
為了把多個事務當成一個事務執行，就必須強制阻止自動提交（第五行）。
第二回合：ThreadLocal
l Spring通過各種模板類降低了開發者使用各種持久技術的難度。
l 這些模板類都是線程安全的。
l 模板類需要綁定數據連接或者會話的資源。
l 這些資源本身是非線程安全的。
l 雖然模板類通過資源池獲取連接或者會話，
l 但是資源池解決的是數據連接或者資源的緩存問題，
l 而不是線程安全問題。
l 按照慣例，採用synchronized進行線程同步。
l 但是該線程同步機制解決具體問題時，開發難度大、降低併發性、影響系統性能。
l 所以，模板類並未採用線程同步機制。
l 那麼，模板類究竟採用什麼方式保證線程安全的呢？
l 答案：ThreadLocal！
ThreadLocal是什麼？
ThreadLocal，顧名思義，它不是一個線程，而是線程的一個本地化對象。多線程程式使用ThreadLocal維護變數時，每一個線程將拿到該變數的一個副本，從而，每個線程對各自變數的副本的更改都不會影響到其他線程。
一個ThreadLocal實例
上例很簡單，三個線程都拿到Integer對象的副本，該Integer對象的初始化值設置為0，然後各自修改，互不影響。
除了set、get、initialValue之外，ThreadLocal還有一個方法：remove(),該方法將當前變數副本從該線程中刪除，減少記憶體的占用。
與Thread同步機制的比較
- 在同步機制中，通過對象的鎖機制保證同一時間只有一個線程訪問變數，該變數是多個線程共用的，那麼，每個線程在什麼時候可以對變數讀寫，什麼時候要對該對象加鎖，什麼時候釋放對象鎖等，都要準確判斷，邏輯複雜，編寫難度大。
- ThreadLoacl為每一個線程提供一個變數的副本，隔離了多線程訪問數據的衝突。ThreadLocal提供了線程安全的對象封裝，在編寫多線程代碼時，可以把不安全的變數封裝進ThreadLocal。
總之，對多線程共用的問題，同步機制採用了”以時間換空間，訪問串列化，對象共用化”。而ThreadLocal則是“以空間換時間，訪問並行化，對象獨享化”。前者只提供一份變數，讓不同的線程排隊訪問，而後者為每一個線程都提供了一份變數，因此可以同時訪問而互不影響。
Spring與ThreadLocal
有狀態就是有數據存儲功能。有狀態對象(Stateful Bean)，就是有實例變數的對象，可以保存數據，是非線程安全的。在不同方法調用間不保留任何狀態。
無狀態就是一次操作，不能保存數據。無狀態對象(Stateless Bean)，就是沒有實例變數的對象.不能保存數據，是不變類，是線程安全的。
一般情況下，只有無狀態bean才可以在多線程環境下共用（既然沒有狀態，不能保存數據，隨便共用啦）
在spring中，絕大部分Bean都可以聲明為singleton作用域。（如果在<bean>中指定Bean的作用範圍是scopt="prototype",那麼系統將bean返回給調用者，spring就不管了（如果兩個實例調用的話，每一次調用都要重新初始化，一個實例的修改不會影響另一個實例的值。如果指定Bean的作用範圍是scope="singleton"，則把bean放到緩衝池中，並將bean的引用返回給調用者。這個時候，如果兩個實例調用的話，因為它們用的是同一個引用，任何一方的修改都會影響到另一方。））
正因為Spring對一些Bean(RequestContextholder、TransactionSynchronizationManager、LocaleContextHolder等)中非線程安全的”狀態性對象”採用ThreadLocal封裝，讓它們成為線程安全的”狀態性對象”，因此有狀態的bean就能夠以singleton方式在多線程中正常工作了。
Spring對有狀態bean的改造思路
非線程安全：
由於第8行的conn是非線程安全的成員變數，
因此addTopic()方法也是非線程安全的，
每次使用時都必須新創建一個TopicDao實例(非singleton)。
對非線程安全的conn進行改造：
上例僅為了簡單說明原理，並不做深究，例子粗糙，並不能在實際環境中使用，還有很多要考慮的其他問題。
第三回合：Spring對事務管理的支持
- 不管選擇Spring JDBC,Hibernate，JPA還是iBatis，Spring都讓我們可以用統一的編程模型進行事務管理。
- Spring事務管理有幾個主要的抽象父類，在事務管理的運作過程中各司其職，主要的功能：
描述事務的隔離級別、超時時間、是否只讀等。
定義事務的屬性，比如事務隔離（當前事務與其他事務的隔離程度）、事務傳播、事務超時、只讀狀態等。
描述事務的具體運行狀態。
- 對應不同的持久化技術，Spring事務管理封裝了具體的實現類。每一種實現類對應的配置方式有所不同。
- Spring使用ThreadLocal技術給不同線程提供各自的數據連接副本。
- Spring通過事務傳播行為來處理事務嵌套調用時的運作。
- Spring聲明式事務管理是通過AOP實現的，通過聲明性信息，Spring負責將事務管理增強邏輯動態織入到業務方法的連接點中。這些邏輯包括：獲取線程綁定資源、開始事務、提交/回滾事務、進行異常轉換和處理等。
- 基於tx/aop命名空間配置事務：在XML中配置目標類、事務管理器、增強類、定義切麵，引入增強等。
- 使用註解配置聲明式事務：@Transactional。
