Spring 事務

從SpringBoot入手,從屁股開始往回學Spring,本次學習事務內容,也有常常被問到你這個spring事務怎麼管理的,這個傳播事務是怎麼處理的等等問題,無論這麼多,一點一點回舔

 

事務

事務指邏輯上的一組操做,要麼所有成功,要麼所有失敗

網上也有不少例子,轉帳的例子最多,賺錢方和收錢方要麼一塊兒成功,要麼一塊兒失敗的過程控制

也有熟悉的數據庫事務的4個特性: 原子性、隔離性、持久性、一致性 

這4個特性從大學就背記了,當時爲了考試,誰管他是什麼,及格纔是王道

原子性:事務是一個不可分隔的工做單元,要麼所有成功,要麼所有失敗

一致性:事務先後數據的完整性必須保持一致

隔離性:多用戶併發訪問數據,某一用戶的事務不會被其餘用戶事務干擾,多個併發事務之間具備互相隔離

持久性:某一事務一旦被提交,它對數據庫中數據的改變是永久的

 

若是不考慮事務隔離性的問題,則會有如下安全性的問題:

髒讀:A事務讀到B事務尚未提交的數據,若是B事務失敗回滾,則A事務讀到的數據就是髒數據

不可重複讀:在同一個事務中,A事務讀取到的B事務已經提交更新的數據,致使A事務不正確,屢次讀取同一數據返回的結果不一樣

幻讀:A事務執行一部分,B事務插入記錄,引發後續的事務的問題

mysql數據庫默認是 repeatable_read

oracle數據庫默認是 read_committed

 

Spring事務管理API

Spring提供一組接口,進行事務管理,主要一下3個:

①PlatformTransactionManager:事務管理器,包含事務狀態、提交、回滾等

spring會根據不一樣的ORM來選擇不一樣的接口實現類,好比下面幾個: 

 

②TransactionDefinition:事務定義信息,包括事務操做的隔離級別、傳播行爲、是否超時、是否只讀等

③TransactionStatus:事務狀態,事務具體的運行狀態,有是不是新事務、是否已經提交、是否完成等等

 

事務傳播行爲

在通常的服務中會有三層結構: web層 、業務層 、持久層

事務通常都會在加在業務層中,假設目前存在下面一些操做方法: 

持久層: Dao0有一個 x方法 ;  Dao1有一個 y方法 ; Dao2有一個 z方法

業務層: Service0 中有一個z方法,同時調用了Dao0.x()和Dao1.y() ; Service1 有一個v方法,調用了Dao2.z()

平時這兩個業務單獨的完成各自的任務接口沒有問題,這時候產品出了一個需求,須要Service0,Service1一塊兒處理一個接口結果

Service0,Service1都有事務,就會出現事務的傳播行爲,如下是七種行爲 : 

前三個是一類,中間三個是一類,最後一個是一類,總共分三類

用第一個說明 ,若是同時調用Service0、Service1的時候,Service0存在事務,則0,1都使用Service0的事務;若是Service0沒有事務,在Service1時,就建立一個事務,將Service0包含在內 --- Service0,Service1會在同一個事務中處理

第二類 Service0,Service1不在同一個事務中

第三類傳播比較複雜,嵌套事務,在一個事務中設置一個保存點標誌,和另外一個事務的成功與否相關

 

-------------------------------------------------------------------