Spring 事務傳播特性和隔離級別
事務是處理邏輯原子性的保證，作為單個邏輯單元執行一系列操作，要么執行完成要么全部不執行。事務遵循ACID四個特性。
事務的兩個重要特性是，事務的傳播特性和事務的隔離級別特性。傳播級別決定了事務的控制范圍，事務隔離級別決定了事務在數據庫讀寫方面的控制范圍。
- 原子性：事務作為一個原子整體，要么執行要么完全不執行
- 一致性：事務保證數據庫狀態從一個一致性變為另一個一致性
- 隔離性：一個事務的執行不影響其他事務的執行
- 持久性：已經提交事務對數據的修改，應該永久保存在數據庫
事務的傳播級別
- PROPAGATION_REQUIRED：Spring的默認傳播級別，如果上下文中存在事務則加入當前事務，如果不存在事務則新建事務執行。
- PROPAGATION_SUPPORTS：如果上下文中存在事務則加入當前事務，如果沒有事務則以非事務方式執行。
- PROPAGATION_MANDATORY：該傳播級別要求上下文中必須存在事務，否則拋出異常。
- PROPAGATION_REQUIRES_NEW：該傳播級別每次執行都會創建新事務，并同時將上下文中的事務掛起，執行完當前線程后再恢復上下文中事務。（子事務的執行結果不影響父事務的執行和回滾）
- PROPAGATION_NOT_SUPPORTED：當上下文中有事務則掛起當前事務，執行完當前邏輯后再恢復上下文事務。（降低事務大小，將非核心的執行邏輯包裹執行。）
- PROPAGATION_NEVER：該傳播級別要求上下文中不能存在事務，否則拋出異常。
- PROPAGATION_NESTED：嵌套事務，如果上下文中存在事務則嵌套執行，如果不存在則新建事務。（save point概念）
事務隔離級別
- 臟讀：讀取到了別的事務回滾前的數據，例如B事務修改數據庫X，在未提交前A事務讀取了X的值，而B事務發生了回滾。
- 不可重復讀：一個事務在兩次讀取同一個數據的值不一致。例如A事務讀取X，在中間過程中B事務修改了X的值，事務A再次讀取X時值發生了改變。
- 幻讀：查詢得到的數據條數發生了改變，例如A事務搜索數據時有10條數據，在這時B事務插入了一條數據，A事務再搜索時發現數據有11條了。
數據隔離級別
- read-uncommitted：未提交讀（臟讀、不可重復讀、幻讀）
- read-committed：已提交讀（不可重復讀、幻讀），大多數主流數據庫的默認事務等級，保證了一個事務不會讀到另一個并行事務已修改但未提交的數據，避免了“臟讀取”。
- repeatable-read：可重復讀（幻讀），保證了一個事務不會修改已經由另一個事務讀取但未提交（回滾）的數據。
- serializable：串行化最嚴格的級別，事務串行執行，資源消耗最大
Spring事務傳播和隔離級別配置
@Transactional(propagation=Propagation.REQUIRED,rollbackFor=Exception.class,timeout=1,isolation=Isolation.DEFAULT)
- 事務的傳播性：@Transactional(propagation=Propagation.REQUIRED) 如果有事務, 那么加入事務, 沒有的話新建一個(默認情況下)
- 事務的超時性：@Transactional(timeout=30) //默認是30秒
- 事務的隔離級別：@Transactional(isolation = Isolation.READ_UNCOMMITTED)
- 回滾：指定異常類：@Transactional(rollbackFor={RuntimeException.class, Exception.class})
- 只讀：@Transactional(readOnly=true)該屬性用于設置當前事務是否為只讀事務，設置為true表示只讀
深入理解事務隔離
未提交讀(Read uncommitted)
未提交讀(READ UNCOMMITTED)是最低的隔離級別。通過名字我們就可以知道，在這種事務隔離級別下，一個事務可以讀到另外一個事務未提交的數據。
未提交讀的數據庫鎖情況（實現原理）
事務在讀數據的時候并未對數據加鎖。
務在修改數據的時候只對數據增加[行級共享鎖]。
現象：
事務1 讀取某行記錄時，事務2也能對這行記錄進行讀取、更新（因為事務一并未對數據增加任何鎖）
事務2 對該記錄進行更新時，事務1再次讀取該記錄，能讀到事務2對該記錄的修改版本（因為事務二只增加了共享讀鎖，事務一可以再增加共享讀鎖讀取數據），即使該修改尚未被提交。
事務1 更新某行記錄時，事務2不能對這行記錄做更新，直到事務1結束。（因為事務一對數據增加了共享讀鎖，事務二不能增加[排他寫鎖]進行數據的修改）
舉例
下面還是借用我在[數據庫的讀現象淺析]一文中舉的例子來說明在未提交讀的隔離級別中兩個事務之間的隔離情況。
事務一共查詢了兩次，在兩次查詢的過程中，事務二對數據進行了修改，并未提交（commit）。但是事務一的第二次查詢查到了事務二的修改結果。在數據庫的讀現象淺析中我們介紹過，這種現象我們稱之為[臟讀]。
所以，未提交讀會導致[臟讀]
提交讀(Read committed)
提交讀(READ COMMITTED)也可以翻譯成讀已提交，通過名字也可以分析出，在一個事務修改數據過程中，如果事務還沒提交，其他事務不能讀該數據。
提交讀的數據庫鎖情況
事務對當前被讀取的數據加 行級共享鎖（當讀到時才加鎖），一旦讀完該行，立即釋放該行級共享鎖；
事務在更新某數據的瞬間（就是發生更新的瞬間），必須先對其加 行級排他鎖，直到事務結束才釋放。
現象：
事務1在讀取某行記錄的整個過程中，事務2都可以對該行記錄進行讀取（因為事務一對該行記錄增加行級共享鎖的情況下，事務二同樣可以對該數據增加共享鎖來讀數據）。
事務1讀取某行的一瞬間，事務2不能修改該行數據，但是，只要事務1讀取完改行數據，事務2就可以對該行數據進行修改。（事務一在讀取的一瞬間會對數據增加共享鎖，任何其他事務都不能對該行數據增加排他鎖。但是事務一只要讀完該行數據，就會釋放行級共享鎖，一旦鎖釋放，事務二就可以對數據增加排他鎖并修改數據）
事務1更新某行記錄時，事務2不能對這行記錄做更新，直到事務1結束。（事務一在更新數據的時候，會對該行數據增加排他鎖，知道事務結束才會釋放鎖，所以，在事務二沒有提交之前，事務一都能不對數據增加共享鎖進行數據的讀取。所以，提交讀可以解決
臟讀的現象）
舉例
在提交讀隔離級別中，在事務二提交之前，事務一不能讀取數據。只有在事務二提交之后，事務一才能讀數據。
但是從上面的例子中我們也看到，事務一兩次讀取的結果并不一致，所以提交讀不能解決。
簡而言之，提交讀這種隔離級別保證了讀到的任何數據都是提交的數據，避免了臟讀(dirty reads)。但是不保證事務重新讀的時候能讀到相同的數據，因為在每次數據讀完之后其他事務可以修改剛才讀到的數據。
可重復讀(Repeatable reads)
可重復讀(REPEATABLE READS),由于提交讀隔離級別會產生不可重復讀的讀現象。所以，比提交讀更高一個級別的隔離級別就可以解決不可重復讀的問題。這種隔離級別就叫可重復讀（這名字起的是不是很任性！）
可重復讀的數據庫鎖情況
事務在讀取某數據的瞬間（就是開始讀取的瞬間），必須先對其加 行級共享鎖，直到事務結束才釋放；
事務在更新某數據的瞬間（就是發生更新的瞬間），必須先對其加 行級排他鎖，直到事務結束才釋放。
現象
事務1在讀取某行記錄的整個過程中，事務2都可以對該行記錄進行讀取（因為事務一對該行記錄增加行級共享鎖的情況下，事務二同樣可以對該數據增加共享鎖來讀數據）。
事務1在讀取某行記錄的整個過程中，事務2都不能修改該行數據（事務一在讀取的整個過程會對數據增加共享鎖，直到事務提交才會釋放鎖，所以整個過程中，任何其他事務都不能對該行數據增加排他鎖。所以，可重復讀能夠解決
不可重復讀的讀現象）事務1更新某行記錄時，事務2不能對這行記錄做更新，直到事務1結束。（事務一在更新數據的時候，會對該行數據增加排他鎖，知道事務結束才會釋放鎖，所以，在事務二沒有提交之前，事務一都能不對數據增加共享鎖進行數據的讀取。所以，提交讀可以解決
臟讀的現象）
舉例
在上面的例子中，只有在事務一提交之后，事務二才能更改該行數據。所以，只要在事務一從開始到結束的這段時間內，無論他讀取該行數據多少次，結果都是一樣的。
從上面的例子中我們可以得到結論：可重復讀隔離級別可以解決不可重復讀的讀現象。但是可重復讀這種隔離級別中，還有另外一種讀現象他解決不了，那就是[幻讀]。看下面的例子：
上面的兩個事務執行情況及現象如下：
事務一的第一次查詢條件是
age BETWEEN 10 AND 30;如果這是有十條記錄符合條件。這時，他會給符合條件的這十條記錄增加行級共享鎖。任何其他事務無法更改這十條記錄。事務二執行一條sql語句，語句的內容是向表中插入一條數據。因為此時沒有任何事務對表增加[表級鎖]，所以，該操作可以順利執行。
事務一再次執行
SELECT * FROM users WHERE age BETWEEN 10 AND 30;時，結果返回的記錄變成了十一條，比剛剛增加了一條，增加的這條正是事務二剛剛插入的那條。
所以，事務一的兩次范圍查詢結果并不相同。這也就是我們提到的幻讀。
可序列化(Serializable)是最高的隔離級別，前面提到的所有的隔離級別都無法解決的幻讀，在可序列化的隔離級別中可以解決。
我們說過，產生幻讀的原因是事務一在進行范圍查詢的時候沒有增加范圍鎖(range-locks：給SELECT 的查詢中使用一個“WHERE”子句描述范圍加鎖），所以導致幻讀。
可序列化的數據庫鎖情況
事務在讀取數據時，必須先對其加 表級共享鎖 ，直到事務結束才釋放；
事務在更新數據時，必須先對其加 表級排他鎖 ，直到事務結束才釋放。
現象:
事務1正在讀取A表中的記錄時，則事務2也能讀取A表，但不能對A表做更新、新增、刪除，直到事務1結束。(因為事務一對表增加了表級共享鎖，其他事務只能增加共享鎖讀取數據，不能進行其他任何操作）
事務1正在更新A表中的記錄時，則事務2不能讀取A表的任意記錄，更不可能對A表做更新、新增、刪除，直到事務1結束。（事務一對表增加了表級排他鎖，其他事務不能對表增加共享鎖或排他鎖，也就無法進行任何操作）
雖然可序列化解決了臟讀、不可重復讀、幻讀等讀現象。但是序列化事務會產生以下效果：
- 無法讀取其它事務已修改但未提交的記錄。
- 在當前事務完成之前，其它事務不能修改目前事務已讀取的記錄。
- 在當前事務完成之前，其它事務所插入的新記錄，其索引鍵值不能在當前事務的任何語句所讀取的索引鍵范圍中。
四種事務隔離級別從隔離程度上越來越高，但同時在并發性上也就越來越低。之所以有這么幾種隔離級別，就是為了方便開發人員在開發過程中根據業務需要選擇最合適的隔離級別。
