翻訳: Introduction to Transaction Management

ここまで、我々が検討してきた基本的なアクセスプリミティブはクエリーである。我々は分散データベースからデータを読み取るだけの取得専用 (または読み取り専用）クエリーに焦点を当ててきた。例えば 2 つのクエリーが同じデータ項目を更新しようとした場合や、クエリーの実行中にシステム障害が発生した場合に何が起こるかについてはまだ検討していない。取得専用クエリーの場合、これらの条件はどちらも問題ではなく、同じデータ項目を同時に読み取るクエリーが 2 つ存在することができる。同様に、システム障害が回復したあとに読み取り専用クエリーを再開することは容易である。一方、更新クエリーの場合では、これらの条件がデータベースに壊滅的な影響を与える可能性があることを察するのは難しくない。例えば特定のデータ項目の値は障害の前にすでに更新されている可能性があり、クエリーの再実行時に再び更新されるべきではないようなことがあるため、システム障害のあとに更新クエリーを再実行することは容易ではない。さもなければデータベースに誤ったデータが含まれることになるだろう。

ここでの基本的なポイントは、クエリーに関する「整合性のある実行 (consistent execution)」または「信頼できる計算 (reliable computation)」という概念が無いことである。トランザクションの概念は整合性と信頼性を持つコンピューティングの基本単位としてデータベースシステムで使用されている。従って、クエリーに対しての実行戦略が決定されプリミティブなデータベース操作に変換されるとそれらはトランザクションとして実行される。

上記の銀論では整合性 (consistent) と信頼性 (reliable) という用語は全く非正規に使用した。議論に置けるそれらの重要性のため、それらをより正確に定義する必要がある。我々はデータベース整合性とトランザクション整合性を区別する。

定義されている全ての整合性 (integrity) 制約に従っている場合、データベースは整合性のある状態にある (Chapter 5 参照)。状態の変更は (更新と呼ばれる) 修正、挿入、削除により発生する。もちろんデータベースが矛盾した状態にならないようにする必要がある。データベースはトランザクション実行中に一時的に矛盾した状態となる可能性がある (通常は矛盾することに注意)。重要な点はトランザクションの終了時にデータベースが整合性を持つことである (Fig.10.1)。

一方でトランザクションの一貫性は並行トランザクションのアクションを指す。データベースに同時にアクセス (読み取りまたは更新) しているユーザリクエストが多数ある場合でも、我々はデータベースに整合性がある状態を維持したいと考えている。複製されたデータベースはその中のすべてのデータ項目の全てのコピーが同じ値を持っている場合、相互に整合性がある状態といえる。これはすべてのレプリカコピーがトランザクションの実行終了時に同じ状態となることを矯正されるためワンコピー等価 (one-copy equivalence) と呼ばれている。レプリカの整合性についてはより緩い概念があって複製の値を分散させることができる。これらについては後述の Chapter 13 で述べる。

信頼性とは、様々なタイプの障害に対するシステムの回復力 (resiliency) とそれらの障害から回復 (recover) する機能の両方を指す。復元力のあるシステムはシステム障害に耐え、障害が発生した場合でもサービスを提供し続けることができる。回復可能な DBMS とは、様々な種類の障害の後に整合性のある状態となる (元の整合性のある状態に戻る、または新しい整合性のある状態に進む) ことである。

トランザクション管理は並列アクセスと障害が起きた場合であっても常にデータベースを整合性のある状態に保つという問題に対処する。以後の 2 つのチャプターではトランザクション管理に関連する問題を調査する。第三章では複製されたデータベースの整合性維持に関連する問題について説明する。本性の目的は、基本的な用語を定義し、これらの問題を論議できる枠組みを提供することである。また、問題および関連する問題の簡潔な紹介も行う。従って概念を高レベルの抽象化されたもので説明し管理手法は提示しない。

この賞の構成は次の通り。次のセクションではトランザクションの概念を正式かつ直感的に定義する。セクション 10.2 ではトランザクションの特徴としてそれらの各特徴がトランザクション管理に関してどのような意味を持つかについて説明する。セクション 10.3 では様々なタイプのトランザクションを紹介する。セクション 10.4 では第一章で定義されたアーキテクチャモデルを再検討し、トランザクション管理をサポートするために必要な変更を示す。

Table of Contents

1. 10.1 トランザクションの定義
   1. 10.1.1 トランザクションの停止条件 [under construction]
   2. 10.1.2 Characterization of Transactions
   3. 10.2.3 Formalization of the Transaction Concept
2. 10.2 Properties of Transactions
   1. 10.2.1 Atomicity
   2. 10.2.2 Consistency
   3. 10.2.3 Isolation
   4. 10.2.4 Durability
3. 10.3 Type of Transactions
   1. 10.3.1 Flat Transactions
   2. 10.3.2 Nested Transactions
   3. 10.3.3 Workflows
4. 10.4 Architecture Revisited
5. 10.5 Conclusion
6. 10.6 Bibliographic Notes
7. 参考文献

10.1 トランザクションの定義

Gray [1981] はトランザクションの概念が契約法に基づいていることを示している。彼はこのように述べている。「契約を結ぶ際、2 人以上の当事者がしばらくの間交渉してから契約を結ぶ。取引は、文書による共同署名またはその他の (握手や頷きのような単純な) 行為によって拘束力を持つ。当事者が互いに特別疑いを持っている場合、または単に安全な取引を行いたい場合は、取引のコミットメントを調整するために仲介者 (通常はエスクローオフィサーと呼ばれる) を任命する。」この歴史的観点の素晴らしい点は、データベースシステムでこの用語が使用されていることに対して、トランザクションのいくつかの基本的な特性 (原子性 (atomicity) と耐久性 (durability)) のいち部を実際に包含していることである。またトランザクションとクエリーの違いを示すのにも役に立っている。

前述の通り、トランザクションは整合性のある信頼できる計算の単位である。従って、直感的にトランザクションはデータベースに対してアクションを実行し、データベースの新しいバージョンを生成して状態遷移を引き起こす。これはクエリーの動作とにているが、トランザクションの実行前にデータベースが整合性を持っていた場合、(1) トランザクションが他のトランザクションと同時に実行された可能性 (2) 実行中に障害が発生した可能性、があるにも拘らず、実行の終了時に整合性があることを保証することができる。

一般に、トランザクションはデータベースに対する一連の読み取り及び書き込み操作と計算ステップで構成されていると見なされる。その意味で、トランザクションはデータベースアクセスクエリー [Paradimitriou, 1986] が埋め込まれたプログラムと考えることもできる。トランザクションのもう一つの定義はプログラムの 1 回の実行であるということである [Ullman, 1988]。単一のクエリーはトランザクションの姿をしているプログラムとして考えることもできる。

例 10.1. (例 5.20 で) 我々が説明した CAD/CAM プロジェクトの予算を 10% 増やすために次のクエリーを考える:

UPDATE PROJ
SET    BUDGET = BUDGET*1.1
WHERE  PNAME= "CAD/CAM"

このクエリーは埋め込み SQL 表記を使用してトランザクション名 (BUDGET_UPDATE など) を指定して次のように宣言することができる。

Begin_transaction BUDGET_UPDATE
begin
  EXEC SQL UPDATE PROJ
       SET BUDGET=BUDGET*1.1
       WHERE PNAME="CAD/CAM"
end

Begin_transaction および end ステートメントはトランザクションの区切りを示す。全ての DBMS で区切りが強制されるわけではない点に注意。区切りが指定されていない場合、DBMS は単にデータベースアクセスを実行するプログラム全体をトランザクションとして処理する場合がある。

例 10.2. トランザクション管理の概念の説明では、最初の 9 章で使用したものの代わりに航空会社の予約システムの例を使用する。実際のこのようなアプリケーション実装ではほとんど常にトランザクションの概念を利用しているだろう。各フライトに関するデータを記録する FLIGHT リレーション、フライトを予約する顧客の CUST リレーションおよびどの顧客がどのフライトを利用しているかを示す FC リレーションが存在すると仮定する。またリレーション定義が次のようになっていると仮定する (下線付きの属性がキーを構成する):

FLIGHT(FNO, DATE, SRC, DST, STSOLD, CAP)
CUST(CNAME, ADDR, VAL)
FC(FNO, DATE, CNAME, SPECIAL)

このデータベーススキーマの属性定義は以下の通り: FNO はフライト番号、DATE はフライト日付、SRC と DEST はフライトの出発地と目的地、STSOLD はそのフライトで販売された座席数を示す。CAP はフライトの乗客定員を示し、CNAME は顧客名を示しその住所は ADDR に保存され、口座残高が BAL、SPECIAL は顧客が予約に対して行うことができる特別な要求に対応する。

旅行代理店がフライト番号、日付、顧客名を入力し予約を要求する典型的な予約アプリケーションの簡易版を考えてみる。この機能を実行するトランザクションは次のように実装できる。データベースアクセスは埋め込み SQL 表記で示されている:

Begin_transaction Reservation
begin
  input(flight_no, date, customer_name); (1)
  EXEC SQL UPDATE FLIGHT  (2)
       SET STSOLD=STSOLD+1
       WHERE FNO=flight_no
       AND DATE=date;
  EXEC SQL INSERT  (3)
       INTO FC(FNO, DATE, CNAME, SPECIAL)
       VALUES(flight_no, date, customer_name, null);
  output("reservation completed")  (4)
end

この例を説明する。先に記法についての注意点だが、埋め込み SQL を使用していると言っても構文に厳密に殉教しているわけではない。小文字の用語はプログラム変数で大文字の用語はデータベースのリレーションと属性、および SQL ステートメントを示している。数値リテラルはそのまま使用されるが、文字列リテラルは引用符で囲まれている。ホスト言語のキーワードで太字で書かれており、null は null 文字列のキーワードである。

トランザクションが最初に行う [行 (1)] はフライト番号、日付、顧客名を入力することである。行 (2) は要求されたフライトの販売済み座席数を一つ更新する。行 (3) は FC リレーションにタプルを挿入している。ここでは既存顧客と想定しているため CUST リレーションに挿入する必要はない。行 (3) のキーワード null はこの顧客が特別な要求をしていないことを示している。最後に行 (4) はトランザクションの結果をエージェントの端末に報告している。

10.1.1 トランザクションの停止条件

例 10.2 の予約トランザクションにはその終了に関する暗黙の仮定が存在する。常に無料の座席が存在することを前提としており、座席の不足によってトランザクションが失敗する可能性があるという事実を考慮していない。これはトランザクションの停止可能性の問題を引き起こす非現実的な仮定である。

Chapter 12 で説明するように、障害が発生した場合でもトランザクションは常に終了する。トランザクションがタスクを正常に完了できる場合、トランザクションはコミットした (commit) と言う。一方、トランザクションがタスクを完了せずに停止した場合は中断した (abort) と言う。トランザクションはいくつかの理由で中断する可能性があるが、それについては今後のチャプターで説明する。この例では、トランザクションがタスクを正常に完了できない状況によってトランザクションはそれ自体を中断する。加えて DBMS は、例えばデッドロックやその他の状況によってトランザクションを中断する場合がある。トランザクションが中断されるとその実行は停止し、データベースを実行前の状態に戻すことによって既に実行された全てのアクションが取り消される。これはロールバック (rollback) とも呼ばれる。

コミットの重要性は2つある。commit コマンドはそのトランザクションの影響をデータベースに反映する必要があることを DBMS に通知する。これにより同じデータ項目にアクセスする他のトランザクションから参照できるようになる。2つ目は、トランザクションがコミットされるポイントは「リターンのないポイント (point of no return)」である。コミットされたトランザクションの結果はデータベースに永続的に保存されもとに戻すことはできない。commit コマンドの実装については Chapter 12 で説明する。

10.1.2 Characterization of Transactions

10.2.3 Formalization of the Transaction Concept

10.2 Properties of Transactions

10.2.1 Atomicity

10.2.2 Consistency

10.2.3 Isolation

10.2.4 Durability

10.3 Type of Transactions

10.3.1 Flat Transactions

10.3.2 Nested Transactions

10.3.3 Workflows

10.4 Architecture Revisited

10.5 Conclusion

10.6 Bibliographic Notes

参考文献

1. M. Tamer Oezsu, Patrick Valduriez, "Principles of Distributed Database Systems", Springer (2019), Chapter 10 Introduction to Transaction Management.