---
# System prepended metadata

title: 18章-3 オブジェクトモデル/データ共有クラスタ
tags: [TransactionalInformationSystems]

---

###### tags: `TransactionalInformationSystems`

# 18章-3 オブジェクトモデル/データ共有クラスタ

## 18.7 オブジェクトモデル分散システムにおけるCC

ここまでの議論をオブジェクトモデルに拡張する。

COCSRやRGの強い特性については、そのまま適用できる。

つまり、ローカルなオブジェクトモデルスケジューラを走らせるサーバが独自にこれらを保証してさえいれば全体がglobally serializableになる。

それよりも弱いチケットを必要とする特性については、チケットの形式がページモデルの単一データアイテムというよりも、GTMからも観測可能なインタフェースを介してアクセスできるアイテムになる（例えば、SQLのレコード）。これは実装の観点からの変更で、それ以外の本質的な変更点はない。

なお、階層的なトランザクション管理が分散システムでは有用になる。
- GTMとLTMという2層構造が、2層スケジュールのCCと自然に対応する。
- GTMはインタフェースとして観測可能な高レベル操作しか参照できない。
    - GTMの各高レベル操作は、独立したページレベルトランザクションとしてサーバに実行される。
    - GTMレイヤは追加で長期のロックを保持し、トランザクション全体の正当性を維持する。
        - トランザクション全体をロールバックするときは、もちろんコミットしてしまった各高レベル操作を相殺する必要がある。

## 18.8 データ共有クラスタにおける一貫性と同時実行制御


15章で一度触れた、データ共有クラスタ（独立にCPUやメモリを持つ複数のコンピュータのストレージが高速なインターコネクトで接続されたサーバ群）に再度踏み込む。

そこで問題になっていたのは、

- 同時実行制御をどうするか
- 複数のサーバに存在するキャッシュをどう管理するか
    - 一つが変更されたとき、他のコピーをどう無効化するか
    - 一つが変更されたとき、他のコピーにその変更をどう伝達するか

の2つ。これを考えていく。

実のところこれらに対する解決策はcallback locking（コールバックロック）として統合的に記述できる。最初に別々に考察した後、最後にコールバックロックに統合する。


### ロック管理による同時実行制御

データ共有クラスタにおいては、各トランザクションは単一のサーバ上で最後まで実行される（他サーバのアイテムにもインターコネクトを介してアクセスできるため）。また、同時実行制御にはロック機構が基本的に使われる。各サーバは一つずつグローバルなロックマネージャとローカルなロックマネージャを持つ。グローバルなロックマネージャへのデータアイテムの割り当て方は静的に決定される。ロックマネージャは割り当てられたデータアイテムへの「グローバルロック権限」を持つ。

グローバルなロックマネージャは、データアイテムへのロックがどの時点で、どのサーバによって、どのモードで取得されたかを保持する。一方、対応するサーバのローカルなロックマネージャは、そのロックを保持するトランザクションの詳細な情報を保持する。

トランザクションがロックを取得あるいは解放したいとき、ローカルマネージャ→グローバルマネージャの順に辿る。ローカルマネージャが一度グローバルマネージャからあるアイテムのロックを許可されたとき、そのローカルマネージャにアイテムのローカル読み込み権限/ローカル書き込み権限が与えられる。

書き込み権限は一つのローカルマネージャにしか与えられず、一方で読み込み権限は複数のローカルマネージャに同時に与えることができる。あるサーバが書き込みを望んだタイミングで、これら複数のローカルマネージャに与えられた権限はグローバルマネージャに回収される。

このロック権限の局所性を活用して、アクセス特性の類似したトランザクションを同じサーバへ分配することによってパフォーマンスを向上することができる。

### キャッシュの一貫性維持

複数のキャッシュの間の一貫性は、オーナベースの手法で維持する。

- 各ページは特定のサーバ（ホーム）に割り当てられる。そのページの最新バージョンキャッシュを持っているサーバ（オーナ）が複数存在しうる。
- 読み込みリクエストをしたサーバは、オーナの一つから最新のキャッシュを受け取って自身をオーナリストに追加する。
- 書き込みリクエストをしたサーバは、オーナリストの全サーバにコールバックリクエストを送り、それらのオーナが持つ古いバージョンのキャッシュを無効にする。


同時実行制御におけるローカルロック権限の分配と、一貫性維持において各オーナが持つキャッシュの概念は非常に似ている。ロックマネージャが管理するデータユニットとキャッシュできる単位を同一視すると、コールバックロックという手法を得る。

#### コールバックロック

- 各ページのグローバルロック権限はホームに帰属する。
- ページの各オーナはそのページのローカル読み込み権限を保持する。
- 書き込みリクエストを行うオーナは、そのページのローカル書き込み権限を保持する。
- ページのコールバックリクエストは、同時にそのページのローカルロック権限をすべて回収する。



最後に、コールバックロックにおいてロック粒度を柔軟にする拡張の手順を考える。

1. ロックを細かい粒度（レコード、オブジェクトなど）でも可能にする。サーバにキャッシュされているページ内のレコードは自由にロック/読み込み/解放できる。ページがキャッシュになかったら、現在のオーナを探す。オーナがいなかったらフェッチして唯一のオーナになる。オーナがいた場合、リクエストしたレコードに書き込みロックをかけているオーナがいなければ、書き込みロックがかけられたレコード全てにunavailableマークを付けたうえでページをフェッチし、オーナの一人になる。これにより、フェッチしたページ内のレコードのうちunavailableでないもの全てのローカル読み込み権限を持つ。レコードへの書き込みを行う際には、そのレコードへのトランザクション終了時まで保持されるロックと、ページへの短期ロックを同時にリクエストする。これによって、unavailableなレコードのオーナを邪魔せずにページをコールバックすることができる。
2. ページ内の複数のレコードを一度に更新したい場合、ページ全体の書き込み権限をリクエストすることで効率化する。
3. レコード読み込みリクエストが他のページレベル書き込みロックと競合していた時、その書き込みロックをde-escalateし、粒度を細かくすることを要求できる。



このようなコールバックロックアルゴリズムの顕著な応用先はCADなど。サーバは全データのホームとして振る舞い、クライアントは最新のデータをローカルにキャッシュする。


