JDBC事務隔離級別

1. 事務基本概念

一組要麼同時執行成功,要麼同時執行失敗的SQL語句。是數據庫操作的一個執行單元。

事務開始點

  • 連接到數據庫上,並執行一條DML語句insert、update或delete
  • 前一個事務結束後,又輸入了另一條DML語句

事務結束點

  • 執行commit或rollback語句。
  • 執行一條DDL語句,例如create table語句,在這種情況下,會自動執行commit語句。
  • 執行一條DDL語句,例如grant語句,在這種情況下,會自動執行commit。

斷開與數據庫的連接

  • 執行了一條DML語句,該語句卻失敗了,在這種情況中,會為這個無效的DML語句執行rollback語句。

2. 事務的四大特點(ACID)

actomicity(原子性)

表示一個事務內的所有操作是一個整體,要麼全部成功,要麼全部失敗

consistency(一致性)

表示一個事務內有一個操作失敗時,所有的更改過的數據都必須回滾到修改前狀態

isolation(隔離性)

事務查看數據時數據所處的狀態,要麼是另一併發事務修改它之前的狀態,要麼是另一事務修改它之後的狀態,事務不會查看中間狀態的數據。

durability(持久性)

持久性事務完成之後,它對於系統的影響是永久性的。

3. 事務隔離級別

SQL標準定義了4類隔離級別,包括了一些具體規則,用來限定事務內外的哪些改變是可見的,哪些是不可見的。低級別的隔離級一般支持更高的併發處理,並擁有更低的系統開銷。

Read Uncommitted(讀取未提交內容)

在該隔離級別,所有事務都可以看到其他未提交事務的執行結果。本隔離級別很少用於實際應用,因為它的性能也不比其他級別好多少。讀取未提交的數據,也被稱之為髒讀(Dirty Read)。

Read Committed(讀取提交內容)

這是大多數數據庫系統的默認隔離級別(但不是MySQL默認的)。它滿足了隔離的簡單定義:一個事務只能看見已經提交事務所做的改變。這種隔離級別 也支持所謂的不可重複讀(Nonrepeatable Read),因為同一事務的其他實例在該實例處理其間可能會有新的commit,所以同一select可能返回不同結果。

Repeatable Read(可重讀)

這是MySQL的默認事務隔離級別,它確保同一事務的多個實例在併發讀取數據時,會看到同樣的數據行。不過理論上,這會導致另一個棘手的問題:幻讀 (Phantom Read)。簡單的說,幻讀指當用戶讀取某一範圍的數據行時,另一個事務又在該範圍內插入了新行,當用戶再讀取該範圍的數據行時,會發現有新的“幻影” 行。InnoDB和Falcon存儲引擎通過多版本併發控制(MVCC,Multiversion Concurrency Control)機制解決了該問題。

Serializable(可串行化)

這是最高的隔離級別,它通過強制事務排序,使之不可能相互衝突,從而解決幻讀問題。簡言之,它是在每個讀的數據行上加上共享鎖。在這個級別,可能導致大量的超時現象和鎖競爭。

這四種隔離級別採取不同的鎖類型來實現,若讀取的是同一個數據的話,就容易發生問題。

例如:

  • 髒讀(Drity Read):某個事務已更新一份數據,另一個事務在此時讀取了同一份數據,由於某些原因,前一個RollBack了操作,則後一個事務所讀取的數據就會是不正確的。
  • 不可重複讀(Non-repeatable read):在一個事務的兩次查詢之中數據不一致,這可能是兩次查詢過程中間插入了一個事務更新的原有的數據。
  • 幻讀(Phantom Read):在一個事務的兩次查詢中數據筆數不一致,例如有一個事務查詢了幾列(Row)數據,而另一個事務卻在此時插入了新的幾列數據,先前的事務在接下來的查詢中,就會發現有幾列數據是它先前所沒有的。

在MySQL中,實現了這四種隔離級別,分別有可能產生問題如下所示:

JDBC事務隔離級別

4. 案例演示事務隔離級別

環境準備

下面,將利用MySQL的客戶端程序,分別測試幾種隔離級別。測試數據庫為test,表為tx;表結構如下:

JDBC事務隔離級別

兩個命令行客戶端分別為A,B;不斷改變A的隔離級別,在B端修改數據。

read uncommitted(未提交讀)

將A的隔離級別設置為 read uncommitted (未提交讀)

在B未更新數據之前:

客戶端A:

JDBC事務隔離級別

B更新數據:

客戶端B:

JDBC事務隔離級別

客戶端A:

JDBC事務隔離級別

經過上面的實驗可以得出結論,事務B更新了一條記錄,但是沒有提交,此時事務A可以查詢出未提交記錄。造成 髒讀 現象。 read uncommitted (未提交讀)是最低的隔離級別。

read committed(已提交讀)

將客戶端A的事務隔離級別設置為 read committed (已提交讀)

在B未更新數據之前:

客戶端A:

JDBC事務隔離級別

B更新數據:

客戶端B:

JDBC事務隔離級別

客戶端A:

JDBC事務隔離級別

經過上面的實驗可以得出結論,已提交讀隔離級別解決了髒讀的問題,但是出現了不可重複讀的問題,即事務A在兩次查詢的數據不一致,因為在兩次查詢之間事務B更新了一條數據。已提交讀只允許讀取已提交的記錄,但不要求可重複讀。

repeatable read(可重複讀)

將A的隔離級別設置為 repeatable read (可重複讀)

在B未更新數據之前:

客戶端A:

JDBC事務隔離級別

B更新數據:

客戶端B:

JDBC事務隔離級別

客戶端A:

JDBC事務隔離級別

B插入數據:

客戶端B:

JDBC事務隔離級別

客戶端A:

JDBC事務隔離級別

由以上的實驗可以得出結論,可重複讀隔離級別只允許讀取已提交記錄,而且在一個事務兩次讀取一個記錄期間,其他事務部的更新該記錄。但該事務不要求與其他事務可串行化。例如,當一個事務可以找到由一個已提交事務更新的記錄,但是可能產生幻讀問題(注意是可能,因為數據庫對隔離級別的實現有所差別)。像以上的實驗,就沒有出現數據幻讀的問題。

Serializable(可串行化)

將A的隔離級別設置為 Serializable (可串行化)

A端打開事務,B端插入一條記錄

事務A端:

JDBC事務隔離級別

事務B端:

JDBC事務隔離級別

因為此時事務A的隔離級別設置為 serializable ,開始事務後,並沒有提交,所以事務B只能等待。

事務A提交事務:

事務A端:

JDBC事務隔離級別

事務B端:

JDBC事務隔離級別

注意: serializable 是完全鎖定字段的,若一個事務來查詢同一份數據就必須等待,直到前一個事務完成並解除鎖定為止 。是完整的隔離級別,會鎖定對應的數據表格,因而會有效率的問題。


分享到:


相關文章: