EJB 事務注意事項

2021-09-12 05:54:07 字數 2702 閱讀 2454

在上篇文章我們提到

,當執行多個事務的時候

,並且這些事務方式資料庫中的相同資料會出現一系列的併發問題

,這些問題彙總起來總共有以下幾類.

丟失更新:撤銷乙個事務時,把其他事務已提交的更新資料覆蓋。

髒讀:乙個事務讀到另乙個事務為提交的更新資料。

不可重複讀:乙個事務讀到另乙個事務已提交的更新資料。

幻像讀:乙個事務讀到另乙個事務已提交的新插入的資料。

丟失更新

當多個事務選擇同一行,然後基於最初選定的值更新該行時,會發生丟失更新問題。每個事務都不知道其它事務的存在。最後的更新將重寫由其它事務所做的更新,這將導致資料丟失。  

舉乙個小例子來幫助進一步理解

:當事務a和事務b同時修改資料庫表的某行的值,

1.事務a將數值改為1

0000

並提交

2.事務b將數值改為2

0000

並提交。這時資料的值為2

0000

,事務a所做的更新將會丟失。

解決辦法:對行加鎖,只允許併發乙個更新事務。髒讀

當第二個事務選擇其它事務正在更新的行時,會發生未確認的相關性問題。第二個事務正在讀取的資料還沒有確認並且可能由更新此行的事務所更改。

1.甲的原工資為1000

0, 乙將甲的工資改為了

15000

,此時但未提交事務.

2.甲讀取自己的工資 ,發現自己的工資變為了

15000!

3.而乙發現操作有誤,回滾了事務,甲的工資又變為了1000015

000是乙個髒資料。

解決辦法:如果在第乙個事務提交前,任何其他事務不可讀取其修改過的值,則可以避免該問題。

非重複讀

當第二個事務多次訪問同一行而且每次讀取不同的資料時,會發生不一致的分析問題。不一致的分析與未確認的相關性類似,因為其它事務也是正在更改第二個事務正在讀取的資料。然而,在不一致的分析中,第二個事務讀取的資料是由已進行了更改的事務提交的。而且,不一致的分析涉及多次(兩次或更多)讀取同一行,而且每次資訊都由其它事務更改;因而該行被非重複讀取。

在乙個事務中前後兩次讀取的結果並不致,導致了不可重複讀。

1.在事務1中,甲讀取了自己的工資為1000

0,操作並沒有完成

2.在事務2中,這時乙修改了甲的工資為

5000

0,並提交了事務.

3.在事務1中,甲再次讀取自己的工資時,工資變為了

50000

解決辦法:如果只有在修改事務完全提交之後才可以讀取資料,則可以避免該問題。

幻像讀     

當對某行執行插入或刪除操作,而該行屬於某個事務正在讀取的行的範圍時,會發生幻像讀問題。事務第一次讀的行範圍顯示出其中一行已不復存在於第二次讀或後續讀中,因為該行已被其它事務刪除。同樣,由於其它事務的插入操作,事務的第二次或後續讀顯示有一行已不存在於原始讀中。

目前工資為1000

0的員工有5人。

1.事務1,讀取所有工資為1000

0的員工。

2.這時事務2向表插入了一條員工記錄,工資也為10000

3.事務1再次讀取所有工資為1000

0的員工共讀取到了

6條記錄,

解決辦法:如果在操作事務完成資料處理之前,任何其他事務都不可以新增新資料,則可避免該問題。

上面所產生的併發問題我們都基本上給出了解決的方案或者建議

,也就是用鎖

.鎖機制能有效地解決併發事務時的各種問題,但是也會影響到併發的效能。資料庫系統提供了相應的解決方案,.

在上文中我們提到

,鎖機制能有效地解決併發事務時的各種問題,但是也會影響到併發的效能。資料庫系統提供了4種可選的事務隔離級別,它們是

1.read uncommited:讀未提交的資料

2.read commited:讀已提交的資料

3.repeateble read:可重複讀

4.serialable:序列化

readuncommited: 該隔離級別讀取資料時不使用任何鎖。可能會出現髒讀,不可重複讀,和虛讀的問題。

readcommited:返回的是讀取時間點之前已提交的資料,因此可以避免髒讀。但重複讀資料時,返回的資料和讀取時間點有關,因此會重現不可重複讀,另外還會出現虛讀現象。

repeatableread:該隔離級別能夠保證重複讀,可以避免髒讀和不可重複讀問題。

serializable:該隔離級別能夠避免髒讀,不可重複讀和虛讀現象,是最嚴格的隔離級別。

上面四種隔離級別,從1-

4隔離級別越來越嚴格,資料安全和真實性越來越高,但併發效能越來越低。所以選擇什麼樣的隔離級別應根據應用的具體要求而定。對於多數應用程式,可以有優先考慮把資料庫系統的隔離級別設為readcommited,它能夠避免髒讀,而且具有較好的併發效能。儘管它會導致不可重複讀、幻像讀這些併發問題,在可能出現這類問題的個別場合,可以由應用程式採用悲觀鎖或樂觀鎖來控制。

a.悲觀鎖:指在應用程式中顯示的為資料資源加鎖。儘管能防止丟失更新和不可重複讀這類併發問題,但是它會影響併發效能,因此應該謹慎地使用。

b.樂觀鎖:樂觀鎖假定當前事務運算元據資源時,不會有其他事務同時訪問該資料資源,因此完全依靠資料庫的隔離級別來自動管理鎖的工作。應用程式採用版本控制手段來避免可能出現的併發問題。,也為

ejb的事務管理做了一系列的鋪墊

,ejb

是如何進行事務管理的.

**

事務注意事項

注意事項 1.在需要事務管理的地方加 transactional註解。transactional 註解可以被應用於介面定義和介面方法 類定義和類的 public 方法上。transactional註解只能應用到 public 可見度的方法上。如果你在 protected private 或者 pac...

事務的注意事項

a.乙個功能是否要事務,必須納入設計 編碼考慮。不能僅僅完成了基本功能就ok。b.如果加了事務,必須做好開發環境測試 測試環境也盡量觸發異常 測試回滾 確保事務生效。c.以下列了事務使用過程的注意事項,請大家留意。1.不要在介面上宣告 transactional 而要在具體類的方法上使用 trans...

事務異常注意事項

主要點 try.catch不會返回物件錯誤或者字段錯誤等型別的錯誤當 set xact abort 為 on 時,如果執行 transact sql 語句產生執行時錯誤,則整個事務將終止並回滾。當 set xact abort 為 off 時,有時只回滾產生錯誤的 transact sql 語句,而...