本文小編為大家詳細介紹“J2EE事務(wù)并發(fā)控制策略知識點有哪些”,內(nèi)容詳細,步驟清晰,細節(jié)處理妥當(dāng),希望這篇“J2EE事務(wù)并發(fā)控制策略知識點有哪些”文章能幫助大家解決疑惑,下面跟著小編的思路慢慢深入,一起來學(xué)習(xí)新知識吧。
創(chuàng)新互聯(lián)專注于阿城網(wǎng)站建設(shè)服務(wù)及定制,我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供阿城營銷型網(wǎng)站建設(shè),阿城網(wǎng)站制作、阿城網(wǎng)頁設(shè)計、阿城網(wǎng)站官網(wǎng)定制、微信小程序定制開發(fā)服務(wù),打造阿城網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供阿城網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。
事務(wù)并發(fā)訪問控制策略
當(dāng)前J2EE項目中,面臨的一個共同問題就是如果控制事務(wù)的并發(fā)訪問,雖然有些持久層框架已經(jīng)為我們做了很多工作,但是理解原理,對于我們開發(fā)來說還是很有用處的。
事務(wù)并發(fā)訪問主要可以分為兩類,分別是同一個系統(tǒng)事務(wù)和跨事務(wù)訪問的并發(fā)訪問控制,其中同一個系統(tǒng)事務(wù)可以采取樂觀鎖以及悲觀鎖策略,而跨多個系統(tǒng)事務(wù)時則需要樂觀離線鎖和悲觀離線鎖。在討論這四種并發(fā)訪問控制策略之前,先需要明確一下數(shù)據(jù)庫事務(wù)隔離級別的問題,ANSI標(biāo)準(zhǔn)規(guī)定了四個數(shù)據(jù)庫事務(wù)隔離級別,它們分別是:
讀取未提交(Read Uncommitted)
這是***的事務(wù)隔離級別,讀事務(wù)不會阻塞讀事務(wù)和寫事務(wù),寫事務(wù)也不會阻塞讀事務(wù),但是會阻塞寫事務(wù)。這樣造成的一個結(jié)果就是當(dāng)一個寫事務(wù)沒有提交的時候,讀事務(wù)照樣可以讀取,那么造成了臟讀的現(xiàn)象。
讀取已提交(Read Committed)
采用此種隔離界別的時候,寫事務(wù)就會阻塞讀事務(wù)和寫事務(wù),但是讀事務(wù)不會阻塞讀事務(wù)和寫事務(wù),這樣因為寫事務(wù)會阻塞讀取事務(wù),那么從而讀取事務(wù)就不能讀到臟數(shù)據(jù),但是因為讀事務(wù)不會阻塞其它的事務(wù),這樣還是會造成不可重復(fù)讀的問題。
可重復(fù)讀(Repeatable Read)
采用此種隔離級別,讀事務(wù)會阻塞寫事務(wù),但是讀事務(wù)不會阻塞讀事務(wù),但是寫事務(wù)會阻塞寫事務(wù)和讀事務(wù)。因為讀事務(wù)阻塞了寫事務(wù),這樣以來就不會造成不可重復(fù)讀的問題,但是這樣還是不能避免幻影讀問題。
序列化(serializable)
此種隔離級別是最嚴格的隔離級別,如果設(shè)置成這個級別,那么就不會出現(xiàn)以上所有的問題(臟讀,不可重復(fù)讀,幻影讀)。但是這樣以來會極大的影響到我們系統(tǒng)的性能,因此我們應(yīng)該避免設(shè)置成為這種隔離級別,相反的,我們應(yīng)該采用較低的隔離界別,然后再采用并發(fā)控制策略來進行事務(wù)的并發(fā)訪問控制)。
其實我們也可以把事務(wù)隔離級別設(shè)置為serializable,這樣就不需要采用并發(fā)控制策略了,數(shù)據(jù)庫就會為我們做好一切并發(fā)控制,但是這樣以來會嚴重影響我們系統(tǒng)的伸縮性和性能,所以在實踐中,我們一般采用讀取已提交或者更低的事務(wù)隔離級別,配合各種并發(fā)訪問控制策略來達到并發(fā)事務(wù)控制的目的。下面總結(jié)一下常用的控制策略:
1 樂觀鎖
樂觀鎖是在同一個數(shù)據(jù)庫事務(wù)中我們常采取的策略,因為它能使得我們的系統(tǒng)保持高的性能的情況下,提高很好的并發(fā)訪問控制。樂觀鎖,顧名思義就是保持一種樂觀的態(tài)度,我們認為系統(tǒng)中的事務(wù)并發(fā)更新不會很頻繁,即使沖突了也沒事,大不了重新再來一次。它的基本思想就是每次提交一個事務(wù)更新時,我們想看看要修改的東西從上次讀取以后有沒有被其它事務(wù)修改過,如果修改過,那么更新就會失敗,。
***我們需要明確一個問題,因為樂觀鎖其實并不會鎖定任何記錄,所以如果我們數(shù)據(jù)庫的事務(wù)隔離級別設(shè)置為讀取已提交或者更低的隔離界別,那么是不能避免不可重復(fù)讀問題的(因為此時讀事務(wù)不會阻塞其它事務(wù)),所以采用樂觀鎖的時候,系統(tǒng)應(yīng)該要容許不可重復(fù)讀問題的出現(xiàn)。
了解了樂觀鎖的概念以后,那么當(dāng)前我們系統(tǒng)中又是如何來使用這種策略的呢?一般可以采用以下三種方法:
版本(Version)字段:在我們的實體中增加一個版本控制字段,每次事務(wù)更新后就將版本字段的值加1.
時間戳(timestamps):采取這種策略后,當(dāng)每次要提交更新的時候就會將系統(tǒng)當(dāng)前時間和實體加載時的時間進行比較,如果不一致,那么就報告樂觀鎖失敗,從而回滾事務(wù)或者重新嘗試提交。采用時間戳有一些不足,比如在集群環(huán)境下,每個節(jié)點的時間同步也許會成問題,并且如果并發(fā)事務(wù)間隔時間小于當(dāng)前平臺最小的時鐘單位,那么就會發(fā)生覆蓋前一個事務(wù)結(jié)果的問題。因此一般采用版本字段比較好。
基于所有屬性進行檢測:采用這種策略的時候,需要比較每個字段在讀取以后有沒有被修改過,所以這種策略實現(xiàn)起來比較麻煩,要求對每個屬性都進行比較,如果采用hiernate的話,因為Hibernate在一級緩存中可以進行臟檢測,那么可以判斷哪些字段被修改過,從而動態(tài)的生成sql語句進行更新。
下面再總結(jié)一下如何在JDBC和Hibernate中使用樂觀鎖:
JDBC中使用樂觀鎖:如果我們采用JDBC來實現(xiàn)持久層的話,那么就可以采用以上將的三種支持樂觀鎖的策略,在實體中增加一個version字段或者一個Date字段,也可以采用基于所有屬性的策略,下面就采用version字段來做一演示:
假如系統(tǒng)中有一個Account的實體類,我們在Account中多加一個version字段,那么我們JDBC Sql語句將如下寫:
Select a.version....from Account as a where
(where condition..) |
這樣以來我們就可以通過更新結(jié)果的行數(shù)來進行判斷,如果更新結(jié)果的行數(shù)為0,那么說明實體從加載以來已經(jīng)被其它事務(wù)更改了,所以就拋出自定義的樂觀鎖定異常(或者也可以采用Spring封裝的異常體系)。具體實例如下:
....... |
在使用JDBC API的情況下,我們需要在每個update語句中,都要進行版本字段的更新以及判斷,因此如果稍不小心就會出現(xiàn)版本字段沒有更新的問題,相反當(dāng)前的 ORM框架卻為我們做好了一切,我們僅僅需要做的就是在每個實體中都增加version或者是Date字段。
Hibernate中使用樂觀鎖:如果我們采用Hibernate做為持久層的框架,那么實現(xiàn)樂觀鎖將變得非常容易,因為框架會幫我們生成相應(yīng)的sql語句,不僅減少了開發(fā)人員的負擔(dān),而且不容易出錯。下面同樣采用version字段的方式來總結(jié)一下:
同樣假如系統(tǒng)中有一個Account的實體類,我們在Account中多加一個version字段,
public class Account{ } |
這樣以來每次我們提交事務(wù)時,hibernate內(nèi)部會生成相應(yīng)的SQL語句將版本字段加1,并且進行相應(yīng)的版本檢測,如果檢測到并發(fā)樂觀鎖定異常,那么就拋出StaleObjectStateException.
2 悲觀鎖
所謂悲觀鎖,顧名思義就是采用一種悲觀的態(tài)度來對待事務(wù)并發(fā)問題,我們認為系統(tǒng)中的并發(fā)更新會非常頻繁,并且事務(wù)失敗了以后重來的開銷很大,這樣以來,我們就需要采用真正意義上的鎖來進行實現(xiàn)。悲觀鎖的基本思想就是每次一個事務(wù)讀取某一條記錄后,就會把這條記錄鎖住,這樣其它的事務(wù)要想更新,必須等以前的事務(wù)提交或者回滾解除鎖。
***我們還是需要明確一個問題,假如我們數(shù)據(jù)庫事務(wù)的隔離級別設(shè)置為讀取已提交或者更低,那么通過悲觀鎖,我們控制了不可重復(fù)讀的問題,但是不能避免幻影讀的問題(因為要想避免我們就需要設(shè)置數(shù)據(jù)庫隔離級別為Serializable,而一般情況下我們都會采取讀取已提交或者更低隔離級別,并配合樂觀或者悲觀鎖來實現(xiàn)并發(fā)控制,所以幻影讀問題是不能避免的,如果想避免幻影讀問題,那么你只能依靠數(shù)據(jù)庫的serializable隔離級別(幸運的是幻影讀問題一般情況下不嚴重)。
下面就分別以JDBC和Hibernate來總結(jié)一下:
JDBC中使用悲觀鎖:在JDBC中使用悲觀鎖,需要使用select for update語句,假如我們系統(tǒng)中有一個Account的類,我們可以采用如下的方式來進行:
Select * from Account where ...(where condition).. for update. |
當(dāng)使用了for update語句后,每次在讀取或者加載一條記錄的時候,都會鎖住被加載的記錄,那么當(dāng)其他事務(wù)如果要更新或者是加載此條記錄就會因為不能獲得鎖而阻塞,這樣就避免了不可重復(fù)讀以及臟讀的問題,但是其他事務(wù)還是可以插入和刪除記錄,這樣也許同一個事務(wù)中的兩次讀取會得到不同的結(jié)果集,但是這不是悲觀鎖鎖造成的問題,這是我們數(shù)據(jù)庫隔離級別所造成的問題。
***還需要注意的一點就是每個沖突的事務(wù)中,我們必須使用select for update 語句來進行數(shù)據(jù)庫的訪問,如果一些事務(wù)沒有使用select for update語句,那么就會很容易造成錯誤,這也是采用JDBC進行悲觀控制的缺點。
Hibernate中使用悲觀鎖:相比于JDBC使用悲觀鎖來說,在Hibernate中使用悲觀鎖將會容易很多,因為Hibernate有API讓我們來調(diào)用,從而避免直接寫SQL語句。下面就Hibernate使用悲觀鎖做一總結(jié):
首先先要明確一下Hibernate中支持悲觀鎖的兩種模式LockMode.UPGRADE以LockMode.UPGRADE_NO_WAIT.(PS:在JPA中,對應(yīng)的鎖模式是LockModeType.Read,這與Hibernate是不一樣的呵呵)
假如我們系統(tǒng)中有一個Account的類,那么具體的操作可以像這樣:
....... 或者也可以采用如下方式來加載對象: |
這樣以來當(dāng)加載對象時,hibernate內(nèi)部會生成相應(yīng)的select for update語句來加載對象,從而鎖定對應(yīng)的記錄,避免其它事務(wù)并發(fā)更新。
讀到這里,這篇“J2EE事務(wù)并發(fā)控制策略知識點有哪些”文章已經(jīng)介紹完畢,想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領(lǐng)會,如果想了解更多相關(guān)內(nèi)容的文章,歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。
標(biāo)題名稱:J2EE事務(wù)并發(fā)控制策略知識點有哪些
當(dāng)前路徑:http://aaarwkj.com/article32/gdegpc.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供關(guān)鍵詞優(yōu)化、網(wǎng)站策劃、云服務(wù)器、響應(yīng)式網(wǎng)站、網(wǎng)站收錄、自適應(yīng)網(wǎng)站
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)