那你的意思是，對數據庫的表進行任何的增刪改查都可以不用考慮併發情況了
SaCoo:10:09:44
這個應該是優先考慮第一個修改這條數據的，然後這個鏈接沒斷開。其他都不能修改這條數據纔對吧？
白蟲子: 10:10:06
都不用考慮
但我剛纔說了, 如果你的新值依賴舊值, 就要考慮這個.
比如你要給某個字段+1, 而不是直接更新成一個值.
獨'孤:10:10:44
恩
白蟲子:10:11:04
我不是舉例子了麼, 你微博改名字, 這個名字就跟舊值無關
但你要給某個賬戶加100塊錢, 就跟舊值有關, 這種情況就不能直接update, 需要考慮bingfa
獨'孤(912274209) 10:11:57
當新值依賴舊值的時候，就可以考慮hibernate的鎖機制了，或者同步機制
恩，對，這樣還能說得通
業務邏輯的實現過程中，往往需要保證數據訪問的排他性。如在金融系統的日終結算處理中，我們希望針對某個cut-off時間點的數據進行處理，而不希望在結算進行過程中（可能是幾秒種，也可能是幾個小時），數據再發生變化。此時，我們就需要通過一些機制來保證這些數據在某個操作過程中不會被外界修改，這樣的機制，在這裏，也就是所謂的“鎖”，即給我們選定的目標數據上鎖，使其無法被其他程序修改。
hibernate支持兩種鎖機制：即通常所說的“悲觀鎖（Pessimistic Locking）”和“樂觀鎖（Optimistic
Locking）”。
悲觀鎖（Pessimistic Locking）
悲觀鎖，正如其名，它指的是對數據被外界（包括本系統當前的其他事務，以及來自外部系統的事務處理）修改持保守態度，因此，在整個數據處理過程中，將數據處於鎖定狀態。悲觀鎖的實現，往往依靠數據庫提供的鎖機制（也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無法保證外部系統不會修改數據）。
一個典型的倚賴數據庫的悲觀鎖調用：
select * from account where name=”Erica” for update
這條sql 語句鎖定了account表中所有符合檢索條件（name=”Erica”）的記錄。
本次事務提交之前（事務提交時會釋放事務過程中的鎖），外界無法修改這些記錄。
Hibernate的悲觀鎖，也是基於數據庫的鎖機制實現。
下面的代碼實現了對查詢記錄的加鎖：
String hqlStr ="from TUser as user where user.name='Erica'";
Query query = session.createQuery(hqlStr);
query.setLockMode("user",LockMode.UPGRADE); //加鎖
List userList = query.list();//執行查詢，獲取數據
query.setLockMode對查詢語句中，特定別名所對應的記錄進行加鎖（我們爲TUser類指定了一個別名“user”），這裏也就是對返回的所有user記錄進行加鎖。
觀察運行期 Hibernate 生成的SQL語句：
select tuser0_.id as id, tuser0_.name as name, tuser0_.group_id as group_id, tuser0_.user_type as user_type, tuser0_.sex as sex
from t_user tuser0_
where (tuser0_.name='Erica' ) for update
這裏 Hibernate 通過使用數據庫的for update子句實現了悲觀鎖機制。
Hibernate的加鎖模式有：
Ø LockMode.NONE ：無鎖機制。
Ø LockMode.WRITE ：Hibernate在Insert和Update記錄的時候會自動獲取。
Ø LockMode.READ ：Hibernate在讀取記錄的時候會自動獲取。
以上這三種鎖機制一般由 Hibernate 內部使用，如Hibernate爲了保證Update過程中對象不會被外界修改，會在save方法實現中自動爲目標對象加上WRITE鎖。
Ø LockMode.UPGRADE ：利用數據庫的for update子句加鎖。
Ø LockMode. UPGRADE_NOWAIT ：Oracle的特定實現，利用Oracle的for update nowait子句實現加鎖。
上面這兩種鎖機制是我們在應用層較爲常用的，加鎖一般通過以下方法實現：
Criteria.setLockMode
Query.setLockMode
Session.lock
注意，只有在查詢開始之前（也就是 Hiberate 生成SQL 之前）設定加鎖，纔會真正通過數據庫的鎖機制進行加鎖處理，否則，數據已經通過不包含for update
子句的Select SQL 加載進來，所謂數據庫加鎖也就無從談起。
樂觀鎖（Optimistic Locking）
相對悲觀鎖而言，樂觀鎖機制採取了更加寬鬆的加鎖機制。悲觀鎖大多數情況下依靠數據庫的鎖機制實現，以保證操作最大程度的獨佔性。但隨之而來的就是數據庫
性能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受。
如一個金融系統，當某個操作員讀取用戶的數據，並在讀出的用戶數據的基礎上進行修改時（如更改用戶帳戶餘額），如果採用悲觀鎖機制，也就意味着整個操作過
程中（從操作員讀出數據、開始修改直至提交修改結果的全過程，甚至還包括操作員中途去煮咖啡的時間），數據庫記錄始終處於加鎖狀態，可以想見，如果面對幾
百上千個併發，這樣的情況將導致怎樣的後果。
樂觀鎖機制在一定程度上解決了這個問題。樂觀鎖，大多是基於數據版本（Version）記錄機制實現。何謂數據版本？即爲數據增加一個版本標識，在基於
數據庫表的版本解決方案中，一般是通過爲數據庫表增加一個 “version”字段來實現。
讀取出數據時，將此版本號一同讀出，之後更新時，對此版本號加一。此時，將提 交數據的版本數據與數據庫表對應記錄的當前版本信息進行比對，如果提交的數據
版本號大於數據庫表當前版本號，則予以更新，否則認爲是過期數據。
對於上面修改用戶帳戶信息的例子而言，假設數據庫中帳戶信息表中有一個version字段，當前值爲1；而當前帳戶餘額字段（balance）爲$100。
1 操作員A此時將其讀出（version=1），並從其帳戶餘額中扣除$50（$100-$50）。
2 在操作員A操作的過程中，操作員B也讀入此用戶信息（version=1），並從其帳戶餘額中扣除$20（$100-$20）。
3 操作員A完成了修改工作，將數據版本號加一（version=2），連同帳戶扣除後餘額（balance=$50），提交至數據庫更新，此時由於提交數據版本大
於數據庫記錄當前版本，數據被更新，數據庫記錄 version 更新爲2。
4 操作員B完成了操作，也將版本號加一（version=2）試圖向數據庫提交數據（balance=$80），但此時比對數據庫記錄版本時發現，操作員B提交的
數據版本號爲 2 ，數據庫記錄當前版本也爲2，不滿足“提交版="true">本必須大於記
錄當前版本才能執行更新 “ 的樂觀鎖策略，因此，操作員B的提交被駁回。這樣，就避免了操作員B用基於version=1的舊數據修改的結果覆蓋操作員A的操作結果的可能。從上面的例子可以看出，樂觀鎖機制避免了長事務中的數據庫加鎖開銷（操作員A和操作員B操作過程中，都沒有對數據庫數據加鎖），大大提升了大併發量下的系統整體性能表現。
需要注意的是，樂觀鎖機制往往基於系統中的數據存儲邏輯，因此也具備一定的侷限性，如在上例中，由於樂觀鎖機制是在我們的系統中實現，來自外部系統的用戶餘額更新操作不受我們系統的控制，因此可能會造成髒數據被更新到數據庫中。在系統設計階段，我們應該充分考慮到這些情況出現的可能性，並進行相應調整（如將樂觀鎖策略在數據庫存儲過程中實現，對外只開放基於此存儲過程的數據更新途徑，而不是將數據庫表直接對外公開）。
Hibernate 在其數據訪問引擎中內置了樂觀鎖實現。如果不用考慮外部系統對數據庫的更新操作，利用Hibernate提供的透明化樂觀鎖實現，將大大提升我們的
生產力。
Hibernate中可以通過class描述符的optimistic-lock屬性結合version
描述符指定。
現在，我們爲之前示例中的 TUser 加上樂觀鎖機制。
1 ． 首先爲TUser的class描述符添加optimistic-lock屬性：
<hibernate-mapping>
<class
name="org.hibernate.sample.TUser"
table="t_user"
dynamic-update="true"
dynamic-insert="true"
optimistic-lock="version"
>
……
</class>
</hibernate-mapping>
optimistic-lock屬性有如下可選取值：
Ø none 無樂觀鎖
Ø version通過版本機制實現樂觀鎖
Ø dirty通過檢查發生變動過的屬性實現樂觀鎖
Ø all通過檢查所有屬性實現樂觀鎖
其中通過 version 實現的樂觀鎖機制是Hibernate官方推薦的樂觀鎖實現，同時也是Hibernate中，目前唯一在數據對象脫離Session發生修改的情況下依然有效的鎖機制。因此，一般情況下，我們都選擇version方式作爲Hibernate樂觀鎖實現機制。
2．添加一個Version屬性描述符
<hibernate-mapping>
<class
name="org.hibernate.sample.TUser"
table="t_user"
dynamic-update="true"
dynamic-insert="true"
optimistic-lock="version"
>
<id
name="id"
column="id"
type="Java.lang.Integer"
>
<generator class="native">
</generator>
</id>
<version
column="version"
name="version"
type="java.lang.Integer"
/>
……
</class>
</hibernate-mapping>
注意version節點必須出現在ID節點之後。
這裏我們聲明瞭一個 version 屬性，用於存放用戶的版本信息，保存在TUser表的
version字段中。
此時如果我們嘗試編寫一段代碼，更新 TUser 表中記錄數據，如：
Criteria criteria = session.createCriteria(TUser.class);
criteria.add(Expression.eq("name","Erica"));
List userList = criteria.list();
TUser user =(TUser)userList.get(0);
Transaction tx = session.beginTransaction();
user.setUserType(1); //更新 UserType字段
tx.commit();
每次對 TUser 進行更新的時候，我們可以發現，數據庫中的version都在遞增。而如果我們嘗試在tx.commit之前，啓動另外一個Session，對名爲Erica的用戶進行操作，以模擬併發更新時的情形：
Session session= getSession();
Criteria criteria = session.createCriteria(TUser.class);
criteria.add(Expression.eq("name","Erica"));
Session session2 = getSession();
Criteria criteria2 = session2.createCriteria(TUser.class);
criteria2.add(Expression.eq("name","Erica"));
List userList = criteria.list();
List userList2 = criteria2.list();TUser user =(TUser)userList.get(0);
TUser user2 =(TUser)userList2.get(0);
Transaction tx = session.beginTransaction();
Transaction tx2 = session2.beginTransaction();
user2.setUserType(99);
tx2.commit();
user.setUserType(1);
tx.commit();
執行以上代碼，代碼將在 tx.commit() 處拋出StaleObjectStateException異
常，並指出版本檢查失敗，當前事務正在試圖提交一個過期數據。通過捕捉這個異常，我
們就可以在樂觀鎖校驗失敗時進行相應處理