本文結合Hibernate以及JPA標準，對J2EE當前持久層設計所遇到的幾個問題進行總結：

事務并發訪問控制策略

當前J2EE項目中，面臨的一個共同問題就是如果控制事務的并發訪問，雖然有些持久層框架已經為我們做了很多工作，但是理解原理，對于我們開發來說還是很有用處的。

事務并發訪問主要可以分為兩類，分別是同一個系統事務和跨事務訪問的并發訪問控制，其中同一個系統事務可以采取樂觀鎖以及悲觀鎖策略，而跨多個系統事務時則需要樂觀離線鎖和悲觀離線鎖。在討論這四種并發訪問控制策略之前，先需要明確一下數據庫事務隔離級別的問題，ANSI標準規定了四個數據庫事務隔離級別，它們分別是：

讀取未提交（Read Uncommitted)

這是***的事務隔離級別，讀事務不會阻塞讀事務和寫事務，寫事務也不會阻塞讀事務，但是會阻塞寫事務。這樣造成的一個結果就是當一個寫事務沒有提交的時候，讀事務照樣可以讀取，那么造成了臟讀的現象。

讀取已提交(Read Committed)

采用此種隔離界別的時候，寫事務就會阻塞讀事務和寫事務，但是讀事務不會阻塞讀事務和寫事務，這樣因為寫事務會阻塞讀取事務，那么從而讀取事務就不能讀到臟數據，但是因為讀事務不會阻塞其它的事務，這樣還是會造成不可重復讀的問題。

可重復讀（Repeatable Read)

采用此種隔離級別，讀事務會阻塞寫事務，但是讀事務不會阻塞讀事務，但是寫事務會阻塞寫事務和讀事務。因為讀事務阻塞了寫事務，這樣以來就不會造成不可重復讀的問題，但是這樣還是不能避免幻影讀問題。

序列化（serializable)

此種隔離級別是最嚴格的隔離級別，如果設置成這個級別，那么就不會出現以上所有的問題（臟讀，不可重復讀，幻影讀）。但是這樣以來會極大的影響到我們系統的性能，因此我們應該避免設置成為這種隔離級別，相反的，我們應該采用較低的隔離界別，然后再采用并發控制策略來進行事務的并發訪問控制）。

其實我們也可以把事務隔離級別設置為serializable，這樣就不需要采用并發控制策略了，數據庫就會為我們做好一切并發控制，但是這樣以來會嚴重影響我們系統的伸縮性和性能，所以在實踐中，我們一般采用讀取已提交或者更低的事務隔離級別，配合各種并發訪問控制策略來達到并發事務控制的目的。下面總結一下常用的控制策略：

1 樂觀鎖

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

***我們需要明確一個問題，因為樂觀鎖其實并不會鎖定任何記錄，所以如果我們數據庫的事務隔離級別設置為讀取已提交或者更低的隔離界別，那么是不能避免不可重復讀問題的（因為此時讀事務不會阻塞其它事務），所以采用樂觀鎖的時候，系統應該要容許不可重復讀問題的出現。

了解了樂觀鎖的概念以后，那么當前我們系統中又是如何來使用這種策略的呢？一般可以采用以下三種方法：

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

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

基于所有屬性進行檢測：采用這種策略的時候，需要比較每個字段在讀取以后有沒有被修改過，所以這種策略實現起來比較麻煩，要求對每個屬性都進行比較，如果采用hiernate的話，因為Hibernate在一級緩存中可以進行臟檢測，那么可以判斷哪些字段被修改過，從而動態的生成sql語句進行更新。

下面再總結一下如何在JDBC和Hibernate中使用樂觀鎖：

#p#

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

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

這樣以來我們就可以通過更新結果的行數來進行判斷，如果更新結果的行數為0，那么說明實體從加載以來已經被其它事務更改了，所以就拋出自定義的樂觀鎖定異常（或者也可以采用Spring封裝的異常體系）。具體實例如下：

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

Hibernate中使用樂觀鎖：如果我們采用Hibernate做為持久層的框架，那么實現樂觀鎖將變得非常容易，因為框架會幫我們生成相應的sql語句，不僅減少了開發人員的負擔，而且不容易出錯。下面同樣采用version字段的方式來總結一下：
同樣假如系統中有一個Account的實體類，我們在Account中多加一個version字段，

這樣以來每次我們提交事務時，hibernate內部會生成相應的SQL語句將版本字段加1，并且進行相應的版本檢測，如果檢測到并發樂觀鎖定異常，那么就拋出StaleObjectStateException.

2 悲觀鎖

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

***我們還是需要明確一個問題，假如我們數據庫事務的隔離級別設置為讀取已提交或者更低，那么通過悲觀鎖，我們控制了不可重復讀的問題，但是不能避免幻影讀的問題（因為要想避免我們就需要設置數據庫隔離級別為Serializable,而一般情況下我們都會采取讀取已提交或者更低隔離級別，并配合樂觀或者悲觀鎖來實現并發控制，所以幻影讀問題是不能避免的，如果想避免幻影讀問題，那么你只能依靠數據庫的serializable隔離級別（幸運的是幻影讀問題一般情況下不嚴重）。

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

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

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

***還需要注意的一點就是每個沖突的事務中，我們必須使用select for update 語句來進行數據庫的訪問，如果一些事務沒有使用select for update語句，那么就會很容易造成錯誤，這也是采用JDBC進行悲觀控制的缺點。

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

首先先要明確一下Hibernate中支持悲觀鎖的兩種模式LockMode.UPGRADE以LockMode.UPGRADE_NO_WAIT.(PS:在JPA中，對應的鎖模式是LockModeType.Read，這與Hibernate是不一樣的呵呵)
假如我們系統中有一個Account的類，那么具體的操作可以像這樣：

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

以上兩種策略都是針對同一個事務而言的，如果我們要實現跨多個事務的并發控制就要采用其它兩種并發控制策略了，下面做一總結：

C++與java是兩種完全不同風格的東西，C++是由程序員創造的，由程序員完善的，然后才出的標準的，也就是說C++的標準完全落后與C++的發展。java恰好相反，它是先有標準（可能還沒有實現），然后后有的實現，而且它是由公司主導開發的，雖然現在開源了，但是標準并不是誰都能定的。這就造就了C++是百花齊放，博大精深，很少有人敢說自己C++很厲害。java卻是另外的一種感覺，一切都規定好了，你只需要按照規定去做，符合標準才可以的。所以C++是那種既可以做的堂堂正正，博大精深（比如標準庫），又可以實現的匪夷所思，天馬行空（寫 Boost庫的人太牛了）。java不行，java要求如此只能如此，不能越雷池一步。

【編輯推薦】

1. Web應用中并發控制的實現
2. Hibernate的事務和并發
3. 詳解Java多線程開發中的數據同步