注意事項:註解方式實現事物,在同一個類中非事物方法調用事物方法,註解失效,緣由註解都是經過aop實現的,不光事物的註解無效,其餘註解也會失效。mysql
Read uncommitted程序員
讀未提交,顧名思義,就是一個事務能夠讀取另外一個未提交事務的數據。spring
事例:老闆要給程序員發工資,程序員的工資是3.6萬/月。可是發工資時老闆不當心按錯了數字,按成3.9萬/月,該錢已經打到程序員的戶口,可是事務尚未提交,就在這時,程序員去查看本身這個月的工資,發現比往常多了3千元,覺得漲工資了很是高興。可是老闆及時發現了不對,立刻回滾差點就提交了的事務,將數字改爲3.6萬再提交。sql
分析:實際程序員這個月的工資仍是3.6萬,可是程序員看到的是3.9萬。他看到的是老闆還沒提交事務時的數據。這就是髒讀。數據庫
那怎麼解決髒讀呢?Read committed!讀提交,能解決髒讀問題。性能
Read committedspa
讀提交,顧名思義,就是一個事務要等另外一個事務提交後才能讀取數據。索引
事例:程序員拿着信用卡去享受生活(卡里固然是隻有3.6萬),當他埋單時(程序員事務開啓),收費系統事先檢測到他的卡里有3.6萬,就在這個時候!!程序員的妻子要把錢所有轉出充當家用,並提交。當收費系統準備扣款時,再檢測卡里的金額,發現已經沒錢了(第二次檢測金額固然要等待妻子轉出金額事務提交完)。程序員就會很鬱悶,明明卡里是有錢的…事務
分析:這就是讀提交,如有事務對數據進行更新(UPDATE)操做時,讀操做事務要等待這個更新操做事務提交後才能讀取數據,能夠解決髒讀問題。但在這個事例中,出現了一個事務範圍內兩個相同的查詢卻返回了不一樣數據,這就是不可重複讀。it
那怎麼解決可能的不可重複讀問題?Repeatable read !
Repeatable read
重複讀,就是在開始讀取數據(事務開啓)時,再也不容許修改操做
事例:程序員拿着信用卡去享受生活(卡里固然是隻有3.6萬),當他埋單時(事務開啓,不容許其餘事務的UPDATE修改操做),收費系統事先檢測到他的卡里有3.6萬。這個時候他的妻子不能轉出金額了。接下來收費系統就能夠扣款了。
分析:重複讀能夠解決不可重複讀問題。寫到這裏,應該明白的一點就是,不可重複讀對應的是修改,即UPDATE操做。可是可能還會有幻讀問題。由於幻讀問題對應的是插入INSERT操做,而不是UPDATE操做。
何時會出現幻讀?
事例:程序員某一天去消費,花了2千元,而後他的妻子去查看他今天的消費記錄(全表掃描FTS,妻子事務開啓),看到確實是花了2千元,就在這個時候,程序員花了1萬買了一部電腦,即新增INSERT了一條消費記錄,並提交。當妻子打印程序員的消費記錄清單時(妻子事務提交),發現花了1.2萬元,彷佛出現了幻覺,這就是幻讀。
那怎麼解決幻讀問題?Serializable!
Serializable 序列化
Serializable 是最高的事務隔離級別,在該級別下,事務串行化順序執行,能夠避免髒讀、不可重複讀與幻讀。可是這種事務隔離級別效率低下,比較耗數據庫性能,通常不使用。
spring中propagation說明
PROPAGATION_REQUIRED:支持當前事務,若是當前沒有事務,就新建一個事務。這是最多見的選擇。
PROPAGATION_SUPPORTS:支持當前事務,若是當前沒有事務,就以非事務方式執行。
PROPAGATION_MANDATORY:支持當前事務,若是當前沒有事務,就拋出異常。
PROPAGATION_REQUIRES_NEW:新建事務,若是當前存在事務,把當前事務掛起。
PROPAGATION_NOT_SUPPORTED:以非事務方式執行操做,若是當前存在事務,就把當前事務掛起。
PROPAGATION_NEVER:以非事務方式執行,若是當前存在事務,則拋出異常。
PROPAGATION_NESTED:支持當前事務,若是當前事務存在,則執行一個嵌套事務(還不是太明白),若是當前沒有事務,就新建一個事務。
spring中isolation對應數據庫的隔離級別
1 ISOLATION_DEFAULT 數據庫默認的隔離級別
下面幾個都是 JDBC isolation levels 一一對應:
2 ISOLATION_READ_UNCOMMITTED ----Read uncommitted
指示防止發生髒讀的常量;不可重複讀和虛讀有可能發生。
3 ISOLATION_READ_COMMITTED ----Read committed
指示能夠發生髒讀 (dirty read)、不可重複讀和虛讀 (phantom read) 的常量。
4 ISOLATION_REPEATABLE_READ ---Repeatable read
指示防止發生髒讀和不可重複讀的常量;虛讀有可能發生。
5 ISOLATION_SERIALIZABLE ----Serializable
for update 對數據庫的影響
場景:根據查詢結果來判斷接下來的處理方案,但在查詢先後結果值可能會發生變化而形成髒讀問題,因此這種時候就須要對查詢信息進行加鎖,這樣其餘事務再要修改其信息時就須要等待當前鎖釋放後再作修改,在mysql中的select * for update是寫鎖,當指明索引時是行鎖,不然是表鎖
注意:只有寫操做,或則讀 for update操做會阻塞
因爲InnoDB預設是Row-Level Lock,因此只有「明確」的指定索引,MySQL纔會執行Row lock (只鎖住被選取的資料例) ,不然MySQL將會執行Table Lock (將整個資料表單給鎖住)。
舉個例子:
假設有個表單products ,裏面有id跟name二個欄位,id是主鍵索引。
例1: (明確指定主鍵索引,而且有此筆資料,row lock)
SELECT * FROM products WHERE id='3' FOR UPDATE;
例2: (明確指定主鍵索引,若查無此筆資料,無lock)
SELECT * FROM products WHERE id='-1' FOR UPDATE;
例2: (無主鍵索引,table lock)
SELECT * FROM products WHERE name='Mouse' FOR UPDATE;
例3: (主鍵索引不明確,table lock)
SELECT * FROM products WHERE id<>'3' FOR UPDATE;
例4: (主鍵索引不明確,table lock)
SELECT * FROM products WHERE id LIKE '3' FOR UPDATE;