ECなどでの開発の場合、当然在庫数によって購入できるか、いなかがかわってきますが、複数人で同時にアクセスする際、処理の整合性を見る必要がでてきますので、ロックのが概念が大事になってきます。
そこでロック処理についてまとめてみようかなと。
ロックについての方針
楽観的ロック
ロックを考える際に、一番簡単なのはバージョンみたいなカラムを用意しておき、処理開始〜更新までにバージョンが更新されていないことを確認して、問題なければ更新処理を行う、といったような処理です。
メリデメを上げると
メリット
- 処理の方法として簡便
- 他の処理をロックしないのでパフォーマンスへの影響が少ない
デメリット
- 競合が発生する可能性を許可してしまう
比較的短時間の処理で使われることが多いと思います。
悲観的ロック
こちらは物理的にDB側で制御してしまうのですが、ある処理が開始して終了するまでは一定の処理(更新onlyのこともあれば参照、更新ともに不可)を行えないようにしてしまう方法です。
参照系などでも在庫の数量を確認する場合、在庫が１つしかないときに、２人の人が同一のタイミングでアクセスされると制御していないと２人とも購入ができてしまいます。
メリット
- 物理的にDBにロックをかけてしまうので、処理の不整合が起きない
デメリット
- 他の処理がブロックされてしまい、その間、一定期間の処理ができないため、パフォーマンスに影響がでる
こちらは比較的長めの重めの処理で使われることが多いかと思います。
ロックの種類
悲観的ロックの際に物理的にDBに制約をかけますが、許可する一定のロックの処理にも種類があります。
共有ロック
処理がおわる(トランザクションの開始から終了)まで、参照はOKだが、更新はNGのような場合です。
占有ロック
読み取りも更新も一切NGにするケースで在庫処理のような場合はこちらを使うのが良いと思われます。
ただしDBの制御によってかわってきたりするので、占有ロックをしても参照できてしまうことなどもあるようです。
