【Wagbyのこだわり】データのロック

複数の利用者がデータを扱う業務アプリケーションでは、別々の利用者が同じデータを編集することがあります。

ここで必要になるのが「ロック処理」です。利用者AさんとBさんが同じデータを編集しようとしたとき、いずれかの編集を「正」とする仕組みのことです。

もしロックがなければ、Aさんの更新を直後にBさんが上書きすることができてしまいます。Aさんは自分の編集データが無効になったことに気づかないため、データ異状を引き起こしてしまいます。

ロックが不要な業務もあります。次のような場合は、ロックを考慮する必要がありません。

ここからわかることは、共通で利用するマスタ系のデータで、複数の利用者が更新権限をもつような場合はロック処理は必須ということです。

ロック処理は「楽観ロック」と「悲観ロック」という二つの方法が知られています。 多くの業務アプリケーションで採用されているのは「楽観ロック」です。ただ、この方式は運用面で使いづらいところがあります。

楽観ロックは次の手順で動作します。

この手順からわかることは、利用者Bが入力したデータは破棄されることです。Bからみた場合、あらためてアプリケーションから最新のデータを取得し、再入力するという手間が生じます。

もう一つの悲観ロックは、次のように動作します。

この手順からわかることは、利用者Bは更新目的でのデータ取得に失敗するため、早い時点で待ち状態になるということです。楽観ロックと異なり、再入力させられるという手間は削減されます。

ただしアプリケーションのつくりは複雑になります。データXを取得する時、単なる閲覧なのか、その後に更新する目的があるのかといった違いを持たせること、そしてアプリケーション自体でロックの仕組みを備える必要があります。

Wagbyの標準は「悲観ロック」です。これを楽観ロックに切り替えることもできます。

そのためWagbyで開発したアプリケーションは、複数利用者の同時更新によるデータ異状というのが発生しないように配慮されています。

Wagbyは楽観ロックであっても悲観ロックであっても、開発者がロックの仕組みを自分で作成する必要はありません。すべてアプリケーションが自動で行います。

例えば楽観ロックをサポートしたノーコード開発ツールで、バージョン値を確認しながら自分で更新判断を行う、というような処理を書かせるような場合、多くのコードを開発する必要に迫られます。これを怠ると更新異状が生じるため手を抜くわけにはいきません。結果として、ノーコード開発ツールでありながら開発生産性は下がるということになりかねません。

お使いのノーコード開発ツールがデータのロックをどういう方針で扱っているのか、知っておくとよいでしょう。