n階層システム設計の考慮点

第7回 データレイヤの設計について

この記事を読むのに必要な時間:およそ 6.5 分

④ 排他制御について

トランザクション制御を設計する上で排他制御についても検討する必要があります。排他制御には大きく分けて2つの方式があります

楽観排他制御(オプティミスティック排他制御)

楽観排他制御は,トランザクションの途中でデータ更新・削除時に対象データが(読み取り時点から)変更されたかどうかを比較し,更新の有無を決定する方法です。更新の有無の判定には一般的に3つの方法があります。

変更項目のつきあわせ

変更対象項目のみを変更前に読みとっておき,更新前に変更の有無を判定する方法。

全項目のつきあわせ

変更対象項目があるレコードのすべてを読みとっておき,更新前に変更の有無を判定する方法。BLOB型などの大容量データがある場合,非現実的となる。

Timestamp 値のつきあわせ

変更対象項目があるレコードの更新タイムスタンプを読みとっておき,更新前に変更の有無を判定する方法。

悲観的排他制御(ペシミスティック排他制御)

悲観的排他制御は,トランザクションの途中で更新対象が変更されないように,データ読み取り時にテーブルロックやロックフラグ,ステータステーブルなどを用いて排他制御を行います。本方式はアプリケーションのパフォーマンス,運用性,操作性に大きく関わってきますので,設計段階での十分な検討が必要です。

また,排他制御とは異なりますが,業務ロジックのルールとして「後勝ち」があります。これは,⁠後から更新・削除したものが先に更新した内容を上書きする」と言うルールで,アプリケーション内で機械的に制御せず,運用で問題を回避する方法です。

これらの排他制御・更新ルールについては業務要件に左右されるため,これといった決め手がないのが現状です。

私が今注目している技術として,⁠Transactional NTFS」があります。これはWindows OS上で管理されているNTFSパーティション上のファイルおよびレジストリに関して,Distributed Transaction Coordinator(DTC)トランザクション,System.Transactions,更新モードのSQLクエリ,MSMQそしてほかのトランザクションと同期を取り,トランザクション管理下での更新を可能とするための技術です。

これにより,アプリケーション内で使用されるファイル・レジストリを一括管理することができるようになります。また,アプリケーションの配布・導入においても,配布のキャンセルや途中でのエラー・例外発生時でも,配布・導入途中までの状態になることやゴミが残ることはなくなります。

Microsoft社は「Transactional NTFS」の発表を行った時にWindows Vistaでの採用をアナウンスしていましたが,現在ではまだ.NET Framework上でのマネージドコードからの使用は実現できていないようです。

「Transactional NTFS」については下記のMicrosoft社のURLを参照してください。

2. サービスエージェントの設計について

ビジネスレイヤのコンポーネントが外部のサービスに接続する必要がある場合,サービスエージェントを経由して接続します。サービスエージェントでは各サービスとの接続手順,データ変換,データのやり取り等のすべてを行い,ビジネスレイヤからこれらを隔離します。

また,サービスとビジネスレイヤ間での通信が長期化する場合は,通信途中の経過をその都度記録しておく必要があります。

サービスエージェントはこれらの機能についての設計を行います。

① サービスエージェントの設計の注意点

サービスエージェントの設計時の注意点について説明します。

1サービスエージェントは1サービスへのアクセスをカプセル化する

1対1の関係にすることにより,サービス側のインターフェイスおよび仕様変更の影響を局所で納めることができます。また,サービスエージェントも小型化・単純化が図れ,パフォーマンス,保守性,拡張性,独立性を保つことができます。

サービス側のデータ変更および呼び出し方法の変更などをビジネスレイヤから分離する

サービス側のインターフェイスおよび仕様変更をサービスエージェント内で吸収することによりビジネスレイヤの独立性を高めることができます。

サービスエージェントのインターフェイスはできるだけビジネスレイヤのビジネスエンティティで定義されたものを使用する

ビジネスエンティティで定義されたものを使用することによって,ビジネスレイヤ内でのデータ型変換の手間が省け,パフォーマンスが向上します。またこの際,型指定がされたビジネスエンティティを使用することによってより効率の向上が見込めます。

サービスエージェント内でサービスからのデータの検証・データ型変換を行う

サービスからのデータの検証は必ず行うようにします。サービスとサービスエージェント間の通信の盗聴・改ざんなどにより,さまざまな脅威が侵入してくる可能性があります。そのため,サービスエージェント内では必ずデータ検証を行うようにします。

また,サービスエージェント内でデータの型変換を行うことにより,ビジネスレイヤへの影響を少なくすることができます。

サービス側でセキュリティチェックが行われていても,アプリケーション側でのセキュリティチェックをサービスエージェント内で行う

セキュリティチェックレベルは各アプリケーションで異なるため,呼び出し側のアプリケーションに適合したセキュリティチェックを行う必要があります。

ただし,サービスとのサービスエージェント間で暗号化通信を行う場合は,同じものを使用する必要があります。

サービスとの通信を特定するために固有IDもしくはGUIDを使用する

これにより,サービスとの通信の特定,非同期通信への対応,通信状態の追跡などが行えるようになります。

サービスエージェント内で完結できるトランザクションはできるだけ完結させる

アプリケーションによって,ビジネスレイヤでトランザクションを生成し,データアクセスロジックコンポーネントや複数のサービスエージェントとのデータのやり取りをしてトランザクションを完結させるものもあるでしょう。この場合,サービスエージェント内で完結できるトランザクションはできるだけ完結できるように設計します。つまり,トランザクションを階層化して設計します。ただし,トランザクションの粒度や排他制御に注意して設計する必要があります。そしてこれらのトランザクションの結果をビジネスレイヤに返し,トランザクションのコミットかロールバックを決定させます。

この場合の設計には十分な事前検証を行い,実現性とリスクを明確にし,検討する必要があります。

著者プロフィール

露木敏博(つゆきとしひろ)

1966年神奈川県横浜市生まれ。1990年,株式会社日立システムアンドサービス(旧日立システムエンジニアリング株式会社)に入社。

流通系SE,営業所駐在SEなどを経て,2003年から生産技術部門で.NET技術に関する技術支援業務に携り,.NET技術に関する各種基準書および標準化,設計ガイドなどを作成。

マイクロソフトMVPアワードプログラムよりDevelopment Platforms - ASP/ASP.NETのカテゴリで2008年7月よりMVPアワードを受賞。