.NETエンタープライズ Webアプリケーション開発技術大全 対話型トランザクション処理の設計方法 マイクロソフト コンサルティング本部　赤間 信幸 2005/04/12

Page1 Page2 Page3

C．楽観同時実行制御を行う

　トランザクション量が多い業務の場合には業務排他制御機能が必要だが、重要マスタデータのメンテナンス業務のように、

• トランザクション量は比較的少ないため、業務排他制御のような「完全な排他的制御」は不要。

• かといって、単純な「後勝ち」ルールだけでは危険なので、アプリケーション的なガードをかけたい。

といった特徴を持つ業務の場合には、次に述べる楽観同時実行制御（Optimistic Concurrency Control）を行うとよい。

　楽観同時実行制御の概念を図8-7に示す。先の業務排他制御とは異なり、楽観同時実行制御では2人以上のユーザが同時にデータの編集作業を行える。そのかわりに、データ更新のタイミングで他のユーザによるデータ更新の有無を確認し、他のユーザがデータを更新していない場合に限って書き込みを行うようにアプリケーションを設計・実装する。

図8-7 楽観同時実行制御による対話型処理の動き

　

図8-8 楽観同時実行制御を利用した場合

　他ユーザによるデータ変更が検知された際には、何らかの後処理を行う。さまざまな対処方法があるが、最もオーソドックスなのは、図8-8のように警告メッセージを表示し、エンドユーザに後処理の方法を選択させるというものである（他の選択肢については本章の後半で解説する）。

　この方法は、更新衝突が発生した場合にエンドユーザが追加操作をしなければならないため、トランザクション量が多く、更新衝突が頻繁に起こりうるような業務には向いていない※6。しかし、この楽観同時実行制御はADO.NETのライブラリ（DataAdapterやDataSetオブジェクト）を利用すると比較的容易に作り込むことができる。またほとんどの場合、データベース上のテーブルへの列追加などのカスタマイズが不要であるというメリットも持つ。

※6 もともと「楽観同時実行制御」という名前は、「おそらくほとんど処理競合・衝突は発生しないので、最初から厳密な排他的制御を行う必要はない」という、「楽観的な見方」をしているところから来ている。このため、衝突確率が高い、あるいは要求された更新を確実にコミットすることが求められるといった、楽観的な見方が許されない業務では業務排他制御の作り込みが必要である。なお楽観同時実行制御との対比から、「衝突は起こるのが当然だとする考え方に基づいて行われる同時実行制御」のことを「悲観同時実行制御（Pessimistic Concurrency Control）」と呼ぶこともある。例えば本章で解説した業務排他制御や、第2章で解説したSQL Serverのロックメカニズムは、いずれもユーザ間での処理衝突が起こることを前提として設計されている。これらは悲観同時実行制御の一種である。

　このため、楽観同時実行制御は、（業務要件として）業務排他制御というところまでのシビアな排他制御は不要だが、かといって単純なデータ上書きでは不十分、というケースでの落としどころとして利用できることが多い。

　ここまで対話型トランザクションの代表的な処理方式を３つ解説したが、いずれの方式でも、データベース上の物理的なロックは必ず短時間で解放されていることに注意して頂きたい。ここまで解説してきた３つの処理方式の比較を表8-1に示す（詳細は以降で解説する）。

　なお、この３つの処理方式はどれかが特に優れているというわけではなく、業務によって向き不向きがある。業務特性を勘案して、適切な処理方式を選択して頂きたい。

	単純なデータ上書き	業務排他制御の作り込み	楽観同時実行制御
概要	同時実行制御を何もしない	業務の入り口で、他のユーザによって編集中となっているか否かをチェックする方式	業務の出口で、他のユーザによるデータ変更有無をチェックする方式
編集状態に入るときに行うチェック	何もしない	他のユーザがデータを編集中か否かをチェックする。また、編集状態に入れた場合には、自分が編集中であることを示す情報を記録しておく	何もしない
複数人による同一データの同時操作	複数人が同時にデータを操作できる	不可、常に1人のみ	複数人が同時にデータを閲覧・操作できる
データを更新するときに行うチェック	何もしない	何もしない	編集中に、他のユーザが当該データを更新していないか否かをチェックする
データの更新時に発生しうる問題	× 強制的に上書きするため、ロストアップデートなどの問題が発生することもある	◎ （システム障害などがない限り）データ更新要求を必ずコミットできる	△ 他のユーザがすでにデータを更新している場合には更新要求が拒否される
データベーススキーマに対する修正	◎ 不要	× 編集状態を記録するために何らかの修正が必要	◎ （基本的には）不要
アプリケーション開発にかかる手間	◎ DataAdapter 構成ウィザードにて「楽観同時実行制御を行わない」という指定をすると、容易に開発できる	× 当該データの編集状態を記録したりチェックしたりするロジックの作り込みが必要	○ DataAdapter やDataSet が持つ機能を利用すると、比較的簡単に開発できる
適している業務	小規模システムでのマスタデータのメンテナンスのように、運用で不整合の発生を十分に回避できるような業務	チケット販売業務のような、データ更新の確実なコミットが要求される業務	重要マスタデータのメンテナンスのように、比較的稀にしか処理競合が発生しないが、確実にアプリケーション側でチェックをかけたいような業務
表8-1 対話型処理の主な3つの処理方式

　以降では、業務排他制御および楽観同時実行制御を用いる場合の、設計上のポイントを解説する※7。

※7 なお本書では完全な実装コードを示すことはせず、設計上のポイントと、断片的な実装コードを示すに留める。余力のある方は、本書に示された断片的なコードを活用して、実際に動作するアプリケーションを完成させてみて頂きたい。

　

.NETエンタープライズWebアプリケーション開発技術大全 Vol.5 トランザクション設計編
	定価4,095円（本体3,900円+税5％） 赤間 信幸（マイクロソフト株式会社コンサルティング本部）　著 B5変型判／416p ISBN4-89100-431-2 日経BPソフトプレス発行 日経BPソフトプレスのページへ マイクロソフトプレスのページへ

　

INDEX
	.NETエンタープライズWebアプリケーション 開発技術大全
	対話型トランザクション処理の設計方法
	1．長時間に渡る排他制御（トランザクション処理）の必要性
	2．対話型トランザクション処理の典型的な設計方法
	3．楽観同時実行制御を行う

　

「.NETエンタープライズWebアプリケーション開発技術大全」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）