問題背景及特點：
我們在使用多用戶數據庫時常常會碰到數據更新失敗、刪除失等情況，如果有多個用戶且同時訪問一個數據庫則當他們的事務同時使用相同的數據時可能會發生並發問題。
並發問題包括：
1.丟失或覆蓋更新。(幻像讀)
2.未確認的相關性（髒讀）。
3.不一致的分析（非重復讀）。
詳細描述：
1.丟失更新
當兩個或多個事務選擇同一行，然後基於最初選定的值更新該行時，會發生丟失更新問題。每個事務都不知道其它事務的存在。最後的更新將重寫由其它事務所做的更新，這將導致數據丟失。
例如，兩個編輯人員制作了同一文檔的電子復本。每個編輯人員獨立地更改其復本，然後保存更改後的復本，這樣就覆蓋了原始文檔。最後保存其更改復本的編輯人員覆蓋了第一個編輯人員所做的更改。如果在第一個編輯人員完成之後第二個編輯人員才能進行更改，則可以避免該問題。
2.未確認的相關性（髒讀）
當第二個事務選擇其它事務正在更新的行時，會發生未確認的相關性問題。第二個事務正在讀取的數據還沒有確認並且可能由更新此行的事務所更改。
例如，一個編輯人員正在更改電子文檔。在更改過程中，另一個編輯人員復制了該文檔（該復本包含到目前為止所做的全部更改）並將其分發給預期的用戶。此後，第一個編輯人員認為目前所做的更改是錯誤的，於是刪除了所做的編輯並保存了文檔。分發給用戶的文檔包含不再存在的編輯內容，並且這些編輯內容應認為從未存在過。如果在第一個編輯人員確定最終更改前任何人都不能讀取更改的文檔，則可以避免該問題。
3.不一致的分析（非重復讀）
當第二個事務多次訪問同一行而且每次讀取不同的數據時，會發生不一致的分析問題。不一致的分析與未確認的相關性類似，因為其它事務也是正在更改第二個事務正在讀取的數據。然而，在不一致的分析中，第二個事務讀取的數據是由已進行了更改的事務提交的。而且，不一致的分析涉及多次（兩次或更多）讀取同一行，而且每次信息都由其它事務更改；因而該行被非重復讀取。
例如，一個編輯人員兩次讀取同一文檔，但在兩次讀取之間，作者重寫了該文檔。當編輯人員第二次讀取文檔時，文檔已更改。原始讀取不可重復。如果只有在作者全部完成編寫後編輯人員才可以讀取文檔，則可以避免該問題。
4.幻像讀
當對某行執行插入或刪除操作，而該行屬於某個事務正在讀取的行的范圍時，會發生幻像讀問題。事務第一次讀的行范圍顯示出其中一行已不復存在於第二次讀或後續讀中，因為該行已被其它事務刪除。同樣，由於其它事務的插入操作，事務的第二次或後續讀顯示有一行已不存在於原始讀中。
例如，一個編輯人員更改作者提交的文檔，但當生產部門將其更改內容合並到該文檔的主復本時，發現作者已將未編輯的新材料添加到該文檔中。如果在編輯人員和生產部門完成對原始文檔的處理之前，任何人都不能將新材料添加到文檔中，則可以避免該問題。
從上面可以看到，解決並發主要是用到了鎖和事務。
鎖 ：給記錄或表加上鎖是為了對當前操作對象加上一個狀態表示位，
讓其它用戶在獲取編輯權限時有了判斷。
事務：是為了保證一組操作的完整性。(要麼就全部成功，要麼就全部失敗)
一般處理並發問題時我這樣做：
1.開啟事務。
2.申請寫權限，也就是給對象(表或記錄)加鎖。
3.如果失敗，則結束事務，過一會重試。
4.如果成功，也就是給對象加鎖成功，防止其它用戶再用同樣的方式打開。
5.進行編輯操作。
6.寫入所進行的編輯結果。
7.如果寫入成功，則提交事務,完成操作。
8.如果寫入失敗，則回滾事務，取消提交。
9.(7.8)兩步操作已釋放了鎖定的對象，恢復到操作前的狀態。
