Spring聲明式事務
Spring聲明式事務讓我們從復雜的事務處理中得到解脫。使得我們再也無需要去處理獲得連接、關閉連接、事務提交和回滾等這些操作。再也無需要我們在與事務相關的方法中處理大量的try…catch…finally代碼。
我們在使用Spring聲明式事務時,有一個非常重要的概念就是事務屬性。事務屬性通常由事務的傳播行為,事務的隔離級別,事務的超時值和事務只讀標志組成。我們在進行事務劃分時,需要進行事務定義,也就是配置事務的屬性。
Spring在TransactionDefinition接口中定義這些屬性,以供PlatfromTransactionManager使用, PlatfromTransactionManager是spring事務管理的核心接口。
- TransactionDefinition
- public interface TransactionDefinition {
- int getPropagationBehavior();
- int getIsolationLevel();
- int getTimeout();
- boolean isReadOnly();
- }
getTimeout()方法,它返回事務必須在多少秒內完成。isReadOnly(),事務是否只讀,事務管理器能夠根據這個返回值進行優化,確保事務是只讀的。getIsolationLevel()方法返回事務的隔離級別,事務管理器根據它來控制另外一個事務可以看到本事務內的哪些數據。
1、ISOLATION_DEFAULT
2、ISOLATION_READ_UNCOMMITTED
3、ISOLATION_READ_COMMITTED
4、ISOLATION_REPEATABLE_READ
5、ISOLATION_SERIALIZABLE
1、ISOLATION_DEFAULT 這是一個PlatfromTransactionManager默認的隔離級別,使用數據庫默認的事務隔離級別.另外四個與JDBC的隔離級別相對應
2、ISOLATION_READ_UNCOMMITTED 這是事務最低的隔離級別,它充許別外一個事務可以看到這個事務未提交的數據。這種隔離級別會產生臟讀,不可重復讀和幻像讀。
例如:
Mary的原工資為1000,財務人員將Mary的工資改為了8000,但未提交事務
- Connection con1 = getConnection();
- con.setAutoCommit(false);
- update employee set salary = 8000 where empId ="Mary";
與此同時,Mary正在讀取自己的工資
- Connection con2 = getConnection();
- select salary from employee where empId ="Mary";
Mary發現自己的工資變為了8000,歡天喜地!而財務發現操作有誤,而回滾了事務,Mary的工資又變為了1000
- //con1
- con1.rollback();
像這樣,Mary記取的工資數8000是一個臟數據。
3、ISOLATION_READ_COMMITTED 保證一個事務修改的數據提交后才能被另外一個事務讀取。另外一個事務不能讀取該事務未提交的數據。這種事務隔離級別可以避免臟讀出現,但是可能會出現不可重復讀和幻像讀。
4、ISOLATION_REPEATABLE_READ 這種事務隔離級別可以防止臟讀,不可重復讀。但是可能出現幻像讀。它除了保證一個事務不能讀取另一個事務未提交的數據外,還保證了避免下面的情況產生(不可重復讀)。
在事務1中,Mary 讀取了自己的工資為1000,操作并沒有完成
- con1 = getConnection();
- select salary from employee empId ="Mary";
在事務2中,這時財務人員修改了Mary的工資為2000,并提交了事務.
- con2 = getConnection();
- update employee set salary = 2000;
- con2.commit();
在事務1中,Mary 再次讀取自己的工資時,工資變為了2000
- //con1
- select salary from employee empId ="Mary";
在一個事務中前后兩次讀取的結果并不致,導致了不可重復讀。
使用ISOLATION_REPEATABLE_READ可以避免這種情況發生。
5、ISOLATION_SERIALIZABLE 這是花費最高代價但是最可靠的事務隔離級別。事務被處理為順序執行。除了防止臟讀,不可重復讀外,還避免了幻像讀。
目前工資為1000的員工有10人。
事務1,讀取所有工資為1000的員工。
- con1 = getConnection();
- Select * from employee where salary =1000;
共讀取10條記錄
這時另一個事務向employee表插入了一條員工記錄,工資也為1000
- con2 = getConnection();
- Insert into employee(empId,salary) values("Lili",1000);
- con2.commit();
事務1再次讀取所有工資為1000的員工
- //con1
- select * from employee where salary =1000;
共讀取到了11條記錄,這就產生了幻像讀。
ISOLATION_SERIALIZABLE能避免這樣的情況發生。但是這樣也耗費了最大的資源。
getPropagationBehavior()返回事務的傳播行為,由是否有一個活動的事務來決定一個事務調用。
在TransactionDefinition接口中定義了七個事務傳播行為。
1、PROPAGATION_REQUIRED
2、PROPAGATION_SUPPORTS
3、PROPAGATION_MANDATORY
4、PROPAGATION_REQUIRES_NEW
5、PROPAGATION_NOT_SUPPORTED
6、PROPAGATION_NEVER
7、PROPAGATION_NESTED
1、PROPAGATION_REQUIRED 如果存在一個事務,則支持當前事務。如果沒有事務則開啟一個新的事務。
- //事務屬性 PROPAGATION_REQUIRED
- methodA{
- ……
- methodB();
- ……
- }
- //事務屬性 PROPAGATION_REQUIRED
- methodB{
- ……
- }
使用spring聲明式事務,spring使用AOP來支持聲明式事務,會根據事務屬性,自動在方法調用之前決定是否開啟一個事務,并在方法執行之后決定事務提交或回滾事務。
【編輯推薦】