DB：「悲観的ロック」と「楽観的ロック」

1.   悲観的ロック 

     悲観的ロックとは、他の処理と競合してはならないトランザクションにおいて、開始時に更新の抑止がされていないことを確認後（抑止されている場合は解除されるまで待機するか、エラーとして処理をあきらめるか）他からの更新を抑止し、完了する際に抑止情報を解除することです。これは排他制御の一種です。

     今の「select for update」はこういう概念です。資料処理の安全と統一性のため保守的なやり方ですが、効率的には良くないです。デッドロックを行う可能性も増えるし、ロック自身でもデータベースに負担を掛けます。また、ロック解除されるまでは待機するので、資料処理の並行性も影響されます。それで、悲観的ロックはトランザクションが短く、頻繁に更新され、なおかつ同時更新が多発するような場合しか使う最終手段です。

メリット

• 資料処理の安全と統一性を守る

     デメリット

• デッドロックを行う可能性も増える
• ロック自身でもデータベースに負担を掛ける
• ロック解除されるまでは待機する (トランザクションが短いので、待機時間はほぼない)

2.   楽観的ロック

     
     悲観的ロックとは、他の処理と競合してはならないトランザクションにおいて、開始時には特に排他処理など行なわず、完了する際に他からの更新がされたか否かを確認し（データのtimestampやversion idで確認する）、もし他から更新されてしまっていたら自らの更新処理を破棄し、エラーとすることです。

     ロックを行なわず直接にデータを更新するので、デッドロックを行うことやデータベースに負担を掛けるを回避できます。資料処理の並行性も守れます。しかし、これは競合激しくないトランザクションしか使えます。同時にデータを読んで更新する場合はまたエラーが発生します。だが、今回はtimestampで確認するので、そういう可能性が低いと思います。悲観的ロックと比べて、悲観的ロックは更新頻度がそれほど高くなく、同時に編集するユーザーが少ないような場合で使う手段です。

     メリット

• デッドロックを行うことを回避できる
• データベースに負担を掛けない
• 資料処理の並行性を守れる

 デメリット

• 同時にデータを読んで更新する場合はエラーが発生する(Timestampやversionをチェックしても解決できない)