排他制御

Web基幹システム(その他でも)を構築しているとよく後勝ち問題に出くわす。

 

  • 後勝ち問題

f:id:Toshi_bw:20190312100234p:plain

後勝ち問題

上記図のように、Aさんが修正画面起動後にBさんが編集画面を起動、

後に修正画面を開いたBさんが先に保存を行い、Aさんが後で保存を行う。

すると、Bさんの修正をAさんは知らない状態なので、Bさんの修正はAさんによって上書きされてしまう。

Bさんは修正したのにされていないこととなってしまう。

 

Bさんは自分は修正できた!と思っているはずなので、何かしらで後々修正されていないことを知ることとなる。

 

業務的にこのようなことが発生する = AさんとBさんがやりたい業務が異なっており、画面の責務を分割すべき、というのももちろんあるが、一旦そこはおいておく。

(例えばAさんは顧客情報を修正しようとしており、Bさんは顧客ステータスのようなものを修正しようとしていたなど)

 

先ほどの図と同じだが、Aさんが保存をしようとした時に「Bさんが保存処理を行なったため、最初からやり直してください」 or 「Bさんが保存処理を行いました、強制的に保存を行うとBさんの修正を上書きしてしまいます」

といった処理。

具体的にはAさんが修正画面起動時に最終更新日時のようなデータを保持しておき、保存時に現在の最終更新日時と比べる。

異なっていればメッセージを表示することにより、知らずに上書きされることをある程度避けることが可能となる。

(ある程度、というのはAさんがいじわるで、強制保存を行い、Bさんに通達しないケース)

 

この処理が向いているのは、更新頻度が低く、更新者があまりいない、マスタ系に向いている。

 

f:id:Toshi_bw:20190312100904p:plain

悲観的排他制御

ほぼ一緒の図だが、今回はBさんは修正開始で終わっている。

Aさんが修正開始したタイミングで、データに編集中フラグのような物を更新する。

Bさんが修正開始しようとしたタイミングで「Aさんが何時何分から修正中です」

とメッセージを表示し、修正できないようにする方法。

Aさん保存時に編集中フラグをOFFに更新することによって、他のユーザが編集可能となる。

Aさんが途中で画面離脱するケースも想定し、何分以上保存されなかった場合は編集中フラグを自動でOFFにする、というJobも必要となる。

 

この処理が向いているのは割と更新頻度が高く、更新対象者も先ほどよりかは多くいるケース、トランザクション向き。

 

 

システム利用経験が少なかったりするユーザの場合、後勝ちを理解していない場合が多いので、システム利用前に予め説明を行い、何かしらの制御を入れるのが良いと思う。

 

 

です!