＜目次＞
(１) 排他制御における楽観ロックと悲観ロックについて
(１-１) 楽観的排他制御
●概要・仕組み
●イメージ図
●楽観的排他制御で起こり得る問題
(１-２) 悲観的排他制御
●概要・仕組み
●イメージ図
●楽観的排他制御で起こり得る問題
(１) 排他制御における楽観ロックと悲観ロックについて
システムにおいて、例えば「誰かが編集している明細を、別の人が開いた時には『読み取り専用モード』で開く、といった要件があった場合、「排他制御」の導入が必要となってきます。今回はその排他制御の種類である「楽観的排他制御」と「悲観的排他制御」の概要についてご紹介します。
(１-１) 楽観的排他制御
●概要・仕組み
「めったなことでは他の人と同時に更新をする事はないだろう」という楽観的な考えのもとに行う排他制御です。
仕組みとして、データ自体にはロックを掛けずに、データを更新しようとしたタイミングで「データが取得したタイミングと同一のものであるか？」をチェックしてから更新する事で、データの整合性を保ちます。つまり、先に更新した方が更新を反映できる「早い者勝ち方式」のようなイメージです。
（図１１１）
楽観ロック方式において、更新しようとしている明細が「取得時と同一のものであるか？」をチェックするために使う情報として、「Version番号」や「タイムスタンプ」等を使用するケースが多いです。
●イメージ図
実際に、複数人が同じ明細を更新しようとした際の流れもイメージをご紹介します。
①AさんとBさんが２人とも同じ明細を取得
（図１１２）
●楽観的排他制御で起こり得る問題
後から更新しようとした人（例ではBさん）が操作した内容が更新されずに破棄されてしまう事が起こり得ます。
(１-２) 悲観的排他制御
●概要・仕組み
「他の人も同じデータを高い頻度で更新するだろう」という悲観的な考えのもとに行う排他制御です。
仕組みとして、更新したい対象のデータを取得するタイミングでデータに対してロックを掛けて、他のトランザクションからは更新できないようにします。
悲観ロック方式において、ロックされているか？を管理するために各明細をロックしてるユーザのID等（DB内にロック者のIDを保持するカラム）の情報を用意し、リアルタイムで明細のロック者を明確にしていきます。ロックされた明細はコミット（確定）やロールバック（取り下げ）するまでは、他のトランザクションからは更新ができません。
●イメージ図
実際に、複数人が同じ明細を更新しようとした際の流れもイメージをご紹介します。
①AさんとBさんが同じ明細を処理しようとして、Aさんが先にロック
（図１２１）
②Bさんも同じ明細を処理しようするも、既にロックされているため更新不可
（図１２２）
③後からBさんが明細を更新
（図１２３）
●悲観的排他制御で起こり得る問題
誰かが明細をロックしたままセッションタイムアウトやサーバダウン等が起こると、明細がロックされたまま残ってしまい、誰も編集できなくなってしまう事が起こりえます。それを防ぐために、ロック解放用の処理を用意したり、ロックの時間制限を設けたり、DBにパッチを当てるなどの仕組みを作る必要があります。
