tombo2-progress’s diary

できるだけ毎日1時間を切り取ってここに晒す。誤字脱字気にしない。日本語が崩壊するのも気にしない。最終的にまとめて本ブログに書く

Transactional Information Systems読む chap2-1

※1: 訳すのが大変。言っていることはわかるけど単語レベル、文脈レベルで意訳を正確にするのはたいへんなので、わかりづらいと思ったら原文を自分で読んでください。

※2: (?)がついている部分は(後述の断りがなく)説明不足と思われるか、僕が理解できなかった部分です。あとで振り返ってわかれば追記するかもしれません

chapter 2

トランザクションを考察する上で一般的なpage modelとobject modelが紹介される。これらは続くpart 2, 3ででのconcurrency controlとrecoveryの基礎になっている。

トランザクション処理を実装する上で一般的な5つのステップ。

  1. データに対する基本的な操作を定義する。 これは不可分な操作であり、他の操作に対してatomicでisolatedなもの
  2. 1の操作をsequenceか部分的に順序たてた処理の並びとしてまとめたトランザクションを構築する。 これはACID特性を保証して、順序通りに実行されなければならないもの
  3. いくつかのトランザクショが並行処理のもとにそれぞれの操作がシャッフルされて実行されるとき、ここから"schedule"か"history"を取り出す
  4. 構文的に(順序的に?)正しい"schedule"からそれらがACIDの観点から正しいと識別しなければならない
  5. 最後に、プログラムが投げてくるように動的(かつ並行)なリクエストに対して、正しいスケジュールを構築できるアルゴリズムプロトコル必用になる

これらの5つのステップは全てのトランザクションモデルで現実的に関連している。

この章の残りでは、これらのステップを2つのトランザクションモデルに当てはめて理解していく。

  • page model

    • read/write modelとしても知られる
    • シンプルなモデルで、データベースのページに読み書きする手法に着目して作られたモデル
    • concurrency controlとrecoveryの問題を理解する上で十分にシンプルかつ多くの(すべてでない)システムの実装上の一般的な問題を説明できる
    • このモデルの制限は、データアクセス操作のセマンティクスを捉えることが出来ないことにある(?)
  • object model

    • page modelより高機能なモデルとしてより高レベル(アクセスレイヤーやクエリープロセッシングレイヤ)のトランザクション処理を考慮している
    • データサーバやアプリケーションサーバに置けるビジネスオブジェクトに対する操作、つまり抽象データ型(ADT, Abstruct data types)からなるトランザクションモデル

これらの2つのモデルの違いは、データオブジェクトの定義ということになる。 page modelではデータは読み書きの操作ができるページであり、object modelはカプセル化された様々な操作ができる一般的なオブジェクトである。

2.3 Page Model

ページモデルの説明に入る前にトランザクションの表現方法の定義と確認。 以下のような記法の確認がある。ここでは書かないので必用ならP.44あたりをチェック。

t = p_1 ... p_n, r(x), w(x), p_{ij}

p45まで。