j2ee的控制策略

J2EE平臺由一整套服務(Services)、應用程式介面(APIs)和協議構成，它對開發基於Web的多層應用提供了功能支援。以下是關於j2ee的控制策略，希望大家認真學習!

J2EE事務併發訪問主要可以分為兩類，分別是同一個系統事務和跨事務訪問的併發訪問控制，其中同一個系統事務可以採取樂觀鎖以及悲觀鎖策略，而跨多個系統事務時則需要樂觀離線鎖和悲觀離線鎖。

樂觀鎖

樂觀鎖是在同一個資料庫事務中我們常採取的策略，因為它能使得我們的系統保持高的效能的情況下，提供很好的併發訪問控制。樂觀鎖，顧名思義就是保持一種樂觀的態度，我們認為系統中的事務併發更新不會很頻繁，即使衝突了也沒事，大不了重新再來一次。它的基本思想就是每次提交一個事務更新時，我們想看看要修改的東西從上次讀取以後有沒有被其它事務修改過，如果修改過，那麼更新就會失敗。

因為樂觀鎖其實並不會鎖定任何記錄，所以資料庫的事務隔離級別設定為讀取已提交或者更低的隔離界別，那麼是不能避免不可重複讀問題的(因為此時讀事務不會阻塞其它事務)，所以採用樂觀鎖的時候，系統應該要容許不可重複讀問題的'出現。

一般可以採用以下三種方法：

版本(Version)欄位：在我們的實體中增加一個版本控制欄位，每次事務更新後就將版本欄位的值加1.

時間戳(timestamps)：採取這種策略後，當每次要提交更新的時候就會將系統當前時間和實體載入時的時間進行比較，如果不一致，那麼就報告樂觀鎖失敗，從而回滾事務或者重新嘗試提交。採用時間戳有一些不足，比如在叢集環境下，每個節點的時間同步也許會成問題，並且如果併發事務間隔時間小於當前平臺最小的時鐘單位，那麼就會發生覆蓋前一個事務結果的問題。因此一般採用版本欄位比較好。

基於所有屬性進行檢測：採用這種策略的時候，需要比較每個欄位在讀取以後有沒有被修改過，所以這種策略實現起來比較麻煩，要求對每個屬性都進行比較，如果採用hibernate的話，因為Hibernate在一級快取中可以進行髒檢測，那麼可以判斷哪些欄位被修改過，從而動態的生成sql語句進行更新。

在JDBC和Hibernate中使用樂觀鎖：

JDBC中使用樂觀鎖：如果我們採用JDBC來實現持久層的話，那麼就可以採用以上將的三種支援樂觀鎖的策略，在實體中增加一個version欄位或者一個Date欄位，也可以採用基於所有屬性的策略，下面就採用version欄位來做一演示：

假如系統中有一個Account的實體類，我們在Account中多加一個version欄位，那麼我們JDBC Sql語句將如下寫：

Select Account as a where (where condition..)

Update Account set version = version+1.....(another field) where version =?...(another contidition)

可以通過更新結果的行數來進行判斷，如果更新結果的行數為0，那麼說明實體從載入以來已經被其它事務更改了，所以就丟擲自定義的樂觀鎖定異常(或者也可以採用Spring封裝的異常體系)。具體例項如下：

introwsUpdated=uteUpdate(sql);

If(rowsUpdated==0){

throwsnewOptimisticLockingFailureException();

}

........

在使用JDBC API的情況下，需要在每個update語句中，都要進行版本欄位的更新以及判斷，因此如果稍不小心就會出現版本欄位沒有更新的問題，相反當前的 ORM框架卻為我們做好了一切，需要做的就是在每個實體中都增加version或者是Date欄位。

Hibernate中使用樂觀鎖：如果採用Hibernate做為持久層的框架，那麼實現樂觀鎖將變得非常容易，因為框架會幫我們生成相應的sql語句，不僅減少了開發人員的負擔，而且不容易出錯。下面同樣採用version欄位的方式來總結一下：

同樣假如系統中有一個Account的實體類，我們在Account中多加一個version欄位，

publicclassAccount{

Longid;

.......

@Version//也可以採用XML檔案進行配置

Intversion

.......

}

提交事務時，hibernate內部會生成相應的SQL語句將版本欄位加1，並且進行相應的版本檢測，如果檢測到併發樂觀鎖定異常，那麼就丟擲StaleObjectStateException.

悲觀鎖

所謂悲觀鎖，顧名思義就是採用一種悲觀的態度來對待事務併發問題，系統中的併發更新會非常頻繁，並且事務失敗了以後重來的開銷很大，這樣就需要採用真正意義上的鎖來進行實現。悲觀鎖的基本思想就是每次一個事務讀取某一條記錄後，就會把這條記錄鎖住，這樣其它的事務要想更新，必須等以前的事務提交或者回滾解除鎖。

最後還是需要明確一個問題，假如資料庫事務的隔離級別設定為讀取已提交或者更低，那麼通過悲觀鎖，控制了不可重複讀的問題，但是不能避免幻影讀的問題(因為要想避免我們就需要設定資料庫隔離級別為Serializable，而一般情況下會採取讀取已提交或者更低隔離級別，並配合樂觀或者悲觀鎖來實現併發控制，所以幻影讀問題是不能避免的，如果想避免幻影讀問題，那麼只能依靠資料庫的serializable隔離級別(幸運的是幻影讀問題一般情況下不嚴重)。

下面就分別以JDBC和Hibernate來總結一下：

JDBC中使用悲觀鎖：在JDBC中使用悲觀鎖，需要使用select for update語句，假如我們系統中有一個Account的類，我們可以採用如下的方式來進行：

Select * from Account where ...(where condition).. for update.

當使用了for update語句後，每次在讀取或者載入一條記錄的時候，都會鎖住被載入的記錄，那麼當其他事務如果要更新或者是載入此條記錄就會因為不能獲得鎖而阻塞，這樣就避免了不可重複讀以及髒讀的問題，但是其他事務還是可以插入和刪除記錄，這樣也許同一個事務中的兩次讀取會得到不同的結果集，但是這不是悲觀鎖所造成的問題，這是資料庫隔離級別所造成的問題。

最後還需要注意的一點就是每個衝突的事務中，必須使用select for update 語句來進行資料庫的訪問，如果一些事務沒有使用select for update語句，那麼就會很容易造成錯誤，這也是採用JDBC進行悲觀控制的缺點。

Hibernate中使用悲觀鎖：相比於JDBC使用悲觀鎖來說，在Hibernate中使用悲觀鎖將會容易很多，因為Hibernate有API讓我們來呼叫，從而避免直接寫SQL語句。下面就Hibernate使用悲觀鎖做一總結：

首先先要明確一下Hibernate中支援悲觀鎖的兩種模式ADE以ADE_NO_WAIT.(PS：在JPA中，對應的鎖模式是，這與Hibernate是不一樣的呵呵)

假如系統中有一個Account的類，那麼具體的操作可以像這樣：

(account,ADE);

或者也可以採用如下方式來載入物件：

(s,identity,ADE).

這樣以來當載入物件時，hibernate內部會生成相應的select for update語句來載入物件，從而鎖定對應的記錄，避免其它事務併發更新。