楽観同時実行制御に適した業務シナリオを考える

[KentaHizume]

背景（議論のモチベーション）

「.NETアプリケーションの処理方式」のトランザクション管理方針では、
排他処理が必要なトランザクションについては、楽観同時実行制御を行うという方針を定めている。

https://maris.alesinfiny.org/app-architecture/overview/dotnet-application-processing-system/transaction-management-policy/#preventing-update-conflicts

しかし、現時点では楽観同時実行制御を行った実装例がないため、Dresscaに実装例を作成したい。
これにあたり、どのような業務シナリオに対して実装するべきか議論したい。

論点（議論のポイント）

• 一般的に、楽観同時実行制御が適した業務シナリオはどのような性質を持つか
• ECサイト（Dressca）の関連業務において、楽観実行制御に適した業務シナリオにはどのようなものが考えられるか
• そのうち、実装およびメンテナンスのコストを考慮してバランスがよいものはどれか

ゴール（この議論のクローズ条件）

• Dresscaにおいて楽観実行制御に適した業務シナリオが特定されること

制約（議論の前提）

• 特になし。

[KentaHizume]

転記およびまとめ

一般的に、楽観同時実行制御が適した業務シナリオはどのような性質を持つか

• 排他制御を行わない場合に不都合が発生すること
  排他制御を行わなかった場合、後勝ち（最後にコミットされたデータがDBに反映される）の状態になる。
  この場合、無視される更新操作が出現してデグレードが発生するが、
  これが発生しても特に困らないシナリオでは、後勝ちのままにしておいて問題ない。
  それゆえ、データの整合性が重要なシナリオのほうが適している。

• 並行して更新操作が行われうるデータを対象としていること
  リソースに対して更新操作を行うアクターが1名の場合、並行して更新しようとする可能性が低い。
  それゆえ、更新操作を行うアクターが2名以上いるシナリオのほうが適している。

[KentaHizume]

ECサイト（Dressca）の関連業務において、楽観実行制御に適した業務シナリオにはどのようなものが考えられるか
そのうち、実装およびメンテナンスのコストを考慮してバランスがよいものはどれか

• MS系のドキュメントでは、マスタ系のデータを複数人が更新する場合が例として挙げられているため、これに該当するシナリオがベストである。
  .NETエンタープライズ Webアプリケーション開発技術大全 対話型トランザクション処理の設計方法
  オプティミスティック同時実行制御を実装する (C#)
  
• しかし、ECサイトのBtoC部分では、マスタ系のデータを複数人が更新するケースが想定しにくかった。
• 没になった案

  • ユーザーの登録情報操作により、ユーザーのプロフィール情報（住所氏名など）が更新
    後勝ちでもあまり不都合がない。

  • ユーザーの決済により、決済のステータス（完了、決済中、未決済）が更新
    没案の中ではアクターが1人なので、発生するケースが想定しにくい。

  • ユーザーの注文により、在庫の数量が更新
    トランザクションの排他制御のシナリオではなく、業務排他のシナリオである。

[KentaHizume]

• 楽観同時実行制御が適したシナリオとして、マスタ系のデータを更新するシナリオが考えられる。
  • カタログアイテム（商品情報のマスタ）の更新
• しかし、現状のDresscaの画面に組み込むべき機能ではないため、これを組み込むために管理機能を持つアプリ一式を実装する。

[KentaHizume]

楽観同時実行制御に適した業務シナリオを特定し、実装するためのissueを起票したため、クローズする。

• Dressca管理アプリを作成する #1453