舉一個實際的例子：我們的系統(tǒng)里有一個商店模塊，商店中重要的一塊是對產(chǎn)品信息的管理，比如運營人員常常會編輯產(chǎn)品的信息，包括產(chǎn)品標(biāo)題，營銷口號和價格等等。因為修改十分頻繁，碰巧同時編輯提交修改的話，就會偶爾遇到修改丟失的問題，運營人員 A 修改產(chǎn)品標(biāo)題，運營人員 B 修改價格，A 和 B 提交修改都提示修改成功，但是結(jié)果上只是 A 的修改結(jié)果生效，B 的修改被 A 的修改沖掉了。
仔細(xì)研究原因，發(fā)現(xiàn)是因為修改功能缺少操作沖突機制，而修改操作同時發(fā)生導(dǎo)致了問題。 如下圖所示，A 和 B 同時從數(shù)據(jù)庫中查詢數(shù)據(jù)，在 web 頁面中修改同樣的數(shù)據(jù)，提交保存時是以 web 頁面中提交的數(shù)據(jù)為準(zhǔn)，從而導(dǎo)致 A 的修改把 B 的修改給覆蓋了。
Rails 的 樂觀鎖Optimistic Locking 是解決這個問題的有力工具，它的原理是在數(shù)據(jù)庫表中增加一個字段（默認(rèn)是 lock_version，可配置）記錄數(shù)據(jù)的版本號，每個提交的修改都帶上這個版本號，在真正 update 修改數(shù)據(jù)之前，先判斷提交的 lock_version 數(shù)據(jù)和數(shù)據(jù)庫中的是否一致，如果不一致，則認(rèn)為發(fā)生數(shù)據(jù)沖突，將拋出 ActiveRecord::StaleObjectError 異常，這樣程序就可以捕獲這個異常，提醒用戶發(fā)生了沖突，由用戶去協(xié)調(diào)解決沖突。
# migration: add lock_version to products
add_column :products, :lock_version, :integer, defalut: 0
# update product with StaleObjectError checking
begin
product.update(params[:product])
rescue ActiveRecord::StaleObjectError
render 'confilct'
end
