Principles of Transaction Processing, 2nd ed.
久野

靖∗

2011.9.1• OS の上に載ったヘンな glue、データベース、通信シ
ステム、アプリケーションプログラミング言語

Philip A. Bernstein, Eric Newcomer, Principles of Transaction Processing, 2nd ed., Morgan Kaufmann, 2009.

0

Preface

0.1

WHY READ THIS BOOK?

• 本書はこれらの謎を解明←それぞれが TP システムの性能、セキュリティ、スケーラビリティ、可用性、保守性、使いやすさにどう影響しているかを説明• 前半では TP ミドルウェアを外→中の順で説明: AP
プログラマにどのような機能をどういう風にして提□ トランザクションプロセシング (TP) は 40 年に渡って供しているか重要なソフトウェア技術であり続けている□ トランザクションという抽象化は DB システムが提供• 交通、金融、小売、通信、製造、行政、軍事• トランザクションは全体として実行され、他のトラン
ザクションと干渉せず、ハード/ソフトの障害があっ• 予約、入出金、株取引、注文処理、音楽/ビデオサー
ビス、出荷追跡、回線交換、在庫管理、指令/制御ても失われない → 本書の後半のテーマ• IBM、HP、Oracle、MS、Dell、Red Hat、EMC• 対象読者: AP プログラマ、DB 管理者、AP アナリス
ト、関連領域の開発者 (DB、OS、通信)、マーケティ• 数$10,000,000,000/year 規模、我々が日常的に使用ング技術者、学部生/院生□ TP システムの動作□ 焦点は「原理」であり、TP システムの作り方ではない• かっては商業データ処理のプロだけが関心• 各種製品に基づく具体例多数←原理がどのように実際に適用されているかが分かるから。特定製品に深

• 今では広く使われていることからより広い範囲の人が知るべき入りはしない• しかし分かりやすい解説はあまりなかった→本書の• 実際に使われている技術に重点を置き、そうでない

目的ものはそこそこに□ 多くの TP 環境は TP ミドルウェアに基づいている□ 前提:

システム的に考えられること。SQL と DB は分かっているものと期待するが、そうでなくても大丈夫• TP ミドルウェア --- 多くのコンポーネントを組み合わせる□ 結果: TP ミドルウェアの働きや、信頼できる分散 TP
システムのためにいつそれを使うべきかが分かる。実際• コンポーネント: フロントエンド (Web サーバ)、中間層 (入力をサービスに接続)、サーバ (ビジネスロの TP ミドルウェアや DB 製品を速やかに学んでそれを活ジック)

用して TP アプリケーションを作れるようになる• TP
ミ ド ル ウェア の 例: IBM CICS、.NET
Enterprise Service、Java EE
製 品
(IBM

0.2

WebSphere Server、Oracle WebLogic Server、
Red Hat JBoss Applicaiton Server)

WHAT’S NEW IN THIS SECONDEDITION□ 初版は 12 年前→そこから大きく変更した。その要因は• 本書の前半は TP ミドルウェアに焦点

おもに 2 つ□ 多くのソフト技術者にとって TP ミドルウェアはよく分□ その 1:からない世界∗ 筑波大学大学院経営システム科学専攻

1

状況の大きな変化• インターネット上の E コマースによる B2B、B2C の普及

分にだけサービスをしてくれ、トランザクション全• サーバや OS のコモディティ化による TP 製品の変化• ブラウザがフロントエンドになり、TP ミドルウェア• 現実には: 多くのトランザクションを並行処理し、
しょっちゅうソフトやハードのエラーが起き (しかもも TP モニタからインターネット向けのさまざまな製

最悪のタイミングで --- あなたのトランザクション

品として発展 (AP サーバ、ORB、メッセージミドルの実行中に)、記憶容量も有限体を完遂してくれ、結果は永遠に残してくれる• にもかかわらず、ソフトウェア的手法を組み合わせ

ウェア、ワークフロー製品)

ることで、その現実の上で理想とするものを実現す• OOP や SOA が主流になり、DB システムが TP 機能をる → 6 〜9 章

きちんと搭載□ その 2:

内容の充実:• 技術の進歩にともなう発展→ 11 章 (クラウド、ス

伝統的 TP システムについてよケーラブルな分散コンピューティング、SDD、ストリー

り広く/深くム/イベント処理)• ワシントン大で教科書として使用してきた。技術の□ 各章のサマリー:

発展に追従• 1 章 はじめに --- TP アプリケーション/システム• TP ミドルウェアについての 3 章 (原理 2 章、実例 1 章) は全面書き換え。例に挙げる製品の充実の全体像。SOA、ACID、2PC、TPC ベンチマーク、可用性、TP 対バッチ/リアルタイム(J2EE、.NET)• 2 章 TP の抽象化 --- TP システムがどのような抽• ビジネスプロセス管理に関する章を新設• ロックに関する章:

楽観的並行制御、B 木ロック、

多粒度ロック、入れ子トランザクションを追加• 新しい章: TPC-E、状態管理、スケーラビリティ、
シャドウページ、データ共有システム、合意アルゴ
リズム、ログベース重複化、複数マスター重複化。

• 全体的に:象化を提供するか。トランザクション、プロセス/ス
レッド、RPC、共有状態 (コンテキスト、セッション、
クッキー)、スケーラビリティ技術 (キャッシング、資源プーリング、パーティショニング、重複化)• 3 章 TP アプリケーションアーキテクチャ --- 多層アーキテクチャの価値と各層の役割。フロントエンド

SOA、REST、Web サービスについて言及(フォーム、Web サーバ)、リクエストコントローラ(トランザクションで囲む)、トランザクションサー
バ (トランザクション実行)。これらと TP ミドルウェ□ サポートページもあります

ア、DB サーバとの対応

0.3

SUMMARY OF TOPICS• 4 章 キューによる TP --- 永続メッセージキューによる信頼性。リカバリシナリオを詳細に説明し、キ□ 多様なニーズ• スポンサー:加しやすいューによる公開/購読型、ブローカ型、バス型ミドル

速く、安く、スケーラブルで、機能追• AP プログラマ:

ウェアの構成を説明。キューマネージャの内部も IBM

Websphere MQ、Oracle Stream AQ を例に説明
TP のさまざまな複雑さからは隔離• 5 章 ビジネスプロセス管理 --- 複数の関連するト

されたい (トランザクションプロトコル、メッセー
ジプロトコル、トランザクション RPC、永続キュー、
マルチスレッド、リソースプール、セッション管理、
重複化プロトコル)の生成/管理/モニタリングをサポートするメカニズ
ムについて。複数トランザクションリクエストにおいて適切な原子性、隔離性、耐久性を得ること。標• AP プログラマの責務: ビジネスが必要とするものを理解し、トランザクションを用いてそれを実現する• システムソフトウェアの仕事:

ランザクションとして実行されるビジネスプロセス

準としての BPEL(ビジネスプロセス実行言語) と実
装例としての MS SQL Service Broker。

速く、効率的で、ス• 6 章 ロッキング --- 2PC がどのように動き、AP プ

ケーラブルで、信頼性のあるシステム → TP ミドル

ログラマがその正しさや性能にどう影響し得るか。

ウェアの役割 → 1〜5 章、＋ 10 章 (現況)

ロックマネージャの実装、デッドロックの対処、ロッ
ク粒度による性能の調整、楽観的手法、バッチ化、□ 理想と現実と実際

ホットスポット除去、隔離度の低い手法、多重バー• TP システムのユーザが考えたいもの: トランザク

ジョン手法、B 木ロッキング、多粒度ロック、入れ子

ションを順次的に処理し、無限に信頼性が高く、自トランザクション。

2

• 7 章 システムリカバリ --- 障害の原因とトランザクションでいかに障害をマスクできるか。チェックポ

もうできているものを与えている (これもダウンロー
ド可能)

イント、ステートレス、ウォーム/ホットスタンバイ、DB におけるロギング (トランザクション/システム/
メディアの障害に対処)、undo/redo パラダイム、ロ
グチェックポイント、リカバリアルゴリズム、シャド
ウページ、ロギング最適化 (ARIES アルゴリズムなど)、アーカイブのリカバリ。

• 8 章 2 相コミット (2PC) --- 2PC プロトコルの詳
細、リカバリの状況分析、ユーザの関与場面。よく使

0.5

ACKNOWLEGMENTS

1

Introduction

1.1

THE BASICS

1.1.1

The Problem

われる最適化 (アボート予約、フェーズ 0、コーディ □ ビジネストランザクション
ネーションの転送)。X/Open トランザクション管理• 現実世界における (企業と企業/個人との) やり取り
(たいていはお金、品物、情報、サービスのやり取り

アーキテクチャを例に DB と TP マネージャのやりと
りを説明。

を伴う)

• 9 章 重複化 --- サーバ重複化と資源重複化のトレー• 何があったかの記帳が必要→コンピュータで (規模、信頼性、コストのため)

ドオフ、正当性基準、1 コピーによる直列化可能。主要な重複化手法 (主要コピー方式、複数マスター方• このための通信もコンピュータ/ネットで→ TP(トラ式)。重複キャッシュの同期、合意アルゴリズム。

ンザクション処理)• 10 章 トランザクションミドルウェアの製品と標
準 --- J2EE、.NET Enterprise Service、旧□ TP における代表的な要求
来 製 品 (CICS、IMS、Tuxedo、ACMS、Pathway)。
• 複数の操作が関与 (支払い+出荷など) →ナイーブな各 種 コ ン ポ ー ネ ン ト (Windows Communication
方法なら簡単だが、規模/信頼性/コストがからむとFoundation、EJB、JDBC、Java Transaction
複雑
API、Spring。標準 (OMB、X/Open、OASIS)。
• 量とデータベース規模→複雑、効率が必須。店員が• 11 章 将来動向 --- TP 技術の主要な方向性。クラ
端末の応答待ちになって待たされたり、Web ページのウド、SDD、データ/イベントストリーム、など。
取り寄せに待たされたりする。企業は「迅速で、低コスト」を求める

0.4

GUIDANCE FOR INSTRUCTORS• 規模+性能のために並行処理が必須だが、制御がな
いと間違った処理。公平性も必要 (Amazon は最初の□ ワシントン大での授業経験• 宿 題 、プ ロ ジェク ト、講 義 ビ デ オ な ど 公 開Xbox 千台の発売時に各顧客のチャンスが公平である
ようにかなり労力を払った)

http://www.cs.washingotn.edu/education/
course/csep545/• トランザクションは全体として実行される必要。支払って品物を受け取るか、どちらも起きないか。エ• いろいろやったが、まず 1 章、つぎに 6 章、7 章をラー (避けられない) が起きた場合でも部分的に実行

やり、宿題と試験でしごいてからコースプロジェク(支払ったが品物は届かない) が起きると問題トに進むのがよかった• プロジェクトは 3 種類:• トランザクションは「OK」「NO」を正しく返すべき。
AP のケーススタディ、商これが無いと顧客はもう 1 度実行した方がいいのか

用製品 (J2EE か.NET) で AP を作ってみる、分散トどうか判断できない

ランザクションを実行する TP ミドルウェアを作って• 漸進的規模拡大。機器を少しずつ買い増すことでスケールしたい。全システム入れ替えや、ましてアプ

みる → 最後のが最も効果的だったのでこれを必須とした

リケーション作り直しは避けたい• 旅行予約システム (飛行機、ホテル、レンタカー) のひな型を作る→ ロック、リカバリ、2PC を実装した• オンラインショップが止まってしまったらその小売店は商売できない。ビジネス活動にとってミッション

リソースマネージャとリクエストを転送できるトラ

クリティカル→ダウンは避けたい

ンザクションミドルウェアの実装が必要 (10 週ではプロの院生でもちょっと大変すぎ)。なので、一部は3

• 完了した取引記録は永続的かつ正当である必要 (金 □ TP サービスを他社に提供する事業者も融では法的要求)。トランザクションが失われてはい• Amazon のサービス、航空予約機能を他者に提供する
けない
航空会社• 地理的に分散していてもうまく稼働する必要→シス• SaaS などによるアウトソース (TP の設置/管理はス
テム自体も分散システムであることが多い。法的要
キルが必要)求のことも (システムはビジネスの起きる地域になければいけない)。また技術的要求 (効率、漸進的規模拡大、障害対策) のことも。

1.1.3• パーソナライゼーションも必要。小売なら各顧客に

A Transaction Program’s Main Function□ TP プログラムのやることは次の 3 つ向けた割引やお勧めなどて、予測可能な形で、かつ低コストで規模拡大可能• (1) ブラウザや他の端末 (POS、センサなど) から入力を受け取るであること。ネットからの顧客数は制御できない• (2) 実際の処理を行う• インターネットからの数百万の顧客の可能性に対し• (3) 応答を作り出し、(おそらく) 返送• 運用が容易であること。さもないと運用スタッフのコストがかさむし、複雑なシステムだと間違いやダ□ 以上の処理を入力ごとに独立して「1 度だけ」行い結果

ウンの可能性が増し、それによりストレスや残業がを「残す」

生じてされにコスト増□ まとめると:□ 多くの TP システムではトランザクションとして実行しTP システムは大変。それをどうやって実ないコードも現するかが本書のテーマ• 情報収集、メンテナンス、データの掃除、再構成、エ• トランザクション自動処理の原理 (従来型、ネット)

ラーチェック…

• そのための基本技術の複雑なところ (ログ、ロック)• 本書ではこれらも TP アプリケーションの一部として扱う• 今日の商用トランザクションミドルウェア (上記機
能を提供)

1.1.2

1.2

What Is a Transaction?

TP SYSTEM ARCHITECTURE□ TP システムは「コンピュータシステムで、トランザク□ TP アプリケーション → トランザクションプログラム

ションプログラムを稼働させているもの」→そのソフトの集まりで、あるビジネス活動を自動化すべく設計されウェア部分の構造:図 1.2

たもの• エンドユーザ機器:□ 最初の OLTP アプリ → SABRE (1960’s、IBM+AA)

エンドユーザ (トランザクショ

ンの実行を要求する人 --- 銀行の顧客、ネット上の• 当時最大のコンピュータシステム、今日でも大規模購買者など) が操作。機器は物理デバイス (レジスなものの 1 つター、ガソリンポンプなど) のことも、PC 上のブラ

• 今日は Sabre ホールディングスが所有し、200 の航

ウザのことも、ダム端末のこともある。スマート端

空会社、何千もの旅行代理店をサポート

末であればアプリのコードを端末上でも実行• 航空券、特殊ミール、マイレージ、機体保守スケジュー• フロントエンドプログラム:

ルなど管理。最大処理能力 20000 メッセージ/秒

エンドユーザ機器とやりとりするアプリケーションコード。メニューやフォームの表示、ユーザ入力の収集をおこなう。ブ□ 今日の TP の用途→図 1.1

ラウザ上で動くコードをサーバから提供することも。

• 初期の TP →大企業による大規模なもの→この部分は今日でも (ネットの発達により) より重要に収集した入力はチェックしてから本体部分に送る• リクエストコントローラ:• さらに今日では (機器や DB、TP ソフトのコスト低下
により)、数端末+サーバ程度の小規模な TP も増加

フロントエンドからの入力を受け取り、適切な (もしかしたら複数の) トラン
ザクションプログラム呼び出しに変換。分散 TP なら(小さい通販店、学校のコース登録、歯科医院の予約など)

メッセージを送る必要。複数プログラムが関与するならその状態を管理• いずれも技術的には同じシステム構造、同じ技術
4• トランザクションサーバ: ユーザの要求した仕事を実行する部分。DB の読み書き、他のプログラムの呼• メッセージを適切なサーバに配送したりトランザク
ション機能をアプリケーションと統合したり分散ト

び出し、結果の作成など

ランザクションを実現• DB システム: アプリケーションが必要とする共有
データを管理□ 例:• 管理ツールと統合されて負荷分散に対応したり使いやすい API を提供

インターネット上の注文処理□ TP ミドルウェアはここ 15 年間で急速に発達してきた• フロントエンドは Web サーバ上で走り、フォームを• WWW の普及以前は TP モニタ、OLTP モニタなどと呼読み書きし、ショッピングカードを管理 (本当か?)ばれて来た• リクエストコントローラは Web サーバからトランザ
クションサーバを呼ぶ• 1990 年代半ば以降、Web サーバ上のトランザクショ
ンのためにアプリケーションサーバが発展• トランザクションサーバは注文を処理 (注文 DB の読
み書き、カタログ情報や在庫情報にアクセス、クレ• 最初は TP モニタとネットの橋渡し機能→やがてアプ
リケーションサーバと TP モニタが統合されるように

ジットカード処理のための別トランザクションを起• 並行して、メッセージ型トランザクションミドルウェ

動など)

アや ORB が普及→ エンタプライズアプリケーション
統合システム□ サーバ上で動くトランザクションプログラムの種類はある程度限定 --- 数十から多くて数百程度• インターネットの標準プロトコルへの対応→ Web サー• それぞれビジネス上の処理に対応 (注文に対応する
出荷、資金の移動など)• ワークフロー製品→長時間実行されるビジネスプロ

ビス→エンタプライズサービスバス
セスに対応• アプリケーションが大きくなった場合、複数のアプ• ミドルウェア製品は環境一式として導入されることが多いが、顧客によっては複数製品の機能を集めてリケーションに分割• それぞれのトランザクションは小規模。典型的ディス
クアクセス数 0〜30、実行命令数数千〜数百万、送受

来て独自環境を構築することもメッセージ数 2〜(場合によるが通常はずっと多い)

1.2.1• 分散されていることが多い (複数のサーバの機能がService Oriented Computing

必要だったり、負荷対応のため同機能のサーバが複 □ SOA(Service Oriented Architecture): ア プ リ
数動いていたりするため)ケーションないしその再利用可能な一部を構成するス
タイルの 1 つ• 動作時間は 1〜2 秒 (ユーザを待たせない、ロック競合を減らす)• 機能が中心となるという点で、OO(「もの」が中心)と対照的□ DB システムの役割は重要 (おそらくアプリケーション
コード自体よりも)• ビジネスサービス (ビジネスが顧客や取引企業に提供するサービス) の概念をモデル化するという点で• メモリに入り切るサイズのこともあるが、もっと大は自然きいことが多い• サービスはオブジェクトにより実現されてもよいが、手続き、メッセージキュー、スクリプトなどで実現• 非揮発性記憶 (磁気ディスク、SDD) を多数搭載することが多い

されてもよい• ディスク技術、DB 技術を最大限活用。重複化や分散化も□ もう 1 つの重要なカテゴリ:• サービスはやりとりするメッセージとインタフェー
スに関する契約 (contracts) により特徴づけられる

トランザクションミドル

(実装プログラムではなくて)ウェア□ サービス指向は概念としては長くあるが…

• TP アプリケーションと下位層 (DB、OS、管理ツール)の中間に位置• 主流になったのは大規模な検索、SNS、e コマースな
どのサイトがサービス指向のアクセスを提供するよ• DB 接続、OS プロセス、通信機能などを効率よく活用うになったためさせてくれ、スケールアップに対応させてくれる

5• その背景は標準的な Web サービスプロトコルの普及 □ サービス化により既存サービスを組み合わせて新しい← 独立したプログラムがそれぞれネット経由で安全サービスを構築することが容易ににかつ信頼できる形で他のプログラムを起動できる• そ の よ う な 組 み 合 わ せ を 容 易 に す る ツ ー ル/ 技という実装技術

法 も 出 現:

Service Component Architecture(Java), Windows Communicaiton Foundation• 多くのベンダが Web サービスプロトコルを提供→マルチベンダ SOA が可能に(Windows)□ SOA を一部または全体として取り入れた TP システム→□ TP アプリも再利用可能なサービスの集まりとして存在

1 つのトランザクションや複数の分散したサービスを用し得る

いて自サービスを提供• その場合でもフロントエンド、リクエストコントロー
ラ、トランザクションサーバの役割は不変• 環境や必要とする機能に応じて同期/非同期通信機能を提供• SOA ベースの TP システムは複数のアプリケーション、OS、ミドルウェア、プラットフォーム、プログラミ
ング言語から組み立て可能• ただし機能のモデル化や設計は変わる必要があるかも• たとえば図 1.2 でリクエストコントローラを Web サー
ビスとして実現するなら、実装技術は WDSL+SOAP などに変更□ 図 1.3 → SOA のコンポーネント• エンドユーザのインタフェースもブラウザから呼ぶように変更するかも (より詳しくは 3 章)

• サービスプロバイダ: サービスを提供、サービスリ
クエスタ: サービスを起動、レジストリ (リポジト □ REST(REpresentational State Transfer): SOA へリ): サービスの記述を公開の代替アプローチ (Web サービスとはかなり違っている)• サービス記述:

インタフェース、交換するデータの• REST という用語は 2 つの違う意味でおもに使われる

名前やフォーマット、通信プロトコル、品質 (セキュ• (1) WWW のためのプロトコルインフラストラクチャ(=HTTP)

リティ、信頼性、トランザクションのふるまいなど)を含む□ 呼び出し方:• (2) WWW プロトコルによって実現可能なソフトウェ

メッセージ送信 (メッセージ交換パター

アアーキテクチャンを参考に)• ここでは (1) の意味 --- REST/HTTP (より詳しく• 基本パターン:は 3.3 節)1 方向の非同期メッセージ (送ったらそれきり、受け取ったら実行するだけ)• 別のパターン:□ レジストリ:□ REST/HTTP ではリソースを少数の汎用的な HTTP 操作

要求=応答型、公開=購読型(GET、PUT、POST、DELETE) を使うことで再利用可能にする無い場合もある• cf. Web サービスでは各アプリケーション固有の呼び出し• 呼び出し側がサービス記述を別の方法で取得する --Web から取れるようになっている、提供側に情報を• 各 HTTP 操作はリソースを表す URI に対して適用

予めもらうなど□ Web サービス:• レジストリ機能により URI を対応するネットワーク

SOA の実装メカニズムの 1 つ

アドレスに変換 (DNS によりドメイン名を IP アドレ• SOAP を使って呼び出す (SOAP は前は Simple Object
Access Protocol だったが SOAP 1.2 では何かの略スに変換することに相当)□ 汎用の HTTP 操作がアプリケーション毎固有の機能に対号ではないことになった)

応づけられる• サ ー ビ ス 記 述 は WSDL(Web Service Descriptio• こ の 記 述 を レ ジ ス ト リ に 登 録 し 、レ ジ ス ト リ は• 例: Web サービスで AddCustomer を呼ぶ → REST
では URI に対する POST

UDDI(Universal Description, Discovery, and• アプリケーション固有の機能やパラメタは URI に埋

Language) によるめ込まれる → REST という名前の由来

Integration) プロトコルで検索可能• 提供側と利用側は別プラットフォーム (例:vs .NET) でも可• 転送に使われる表現形式としては JSON などの標準的形式が使われる

JavaEE

6□ どの表現形式を使うかは HTTP の content-type ヘッダ、• TP システム: 1 つ以上の TP アプリケーションをサポートするシステム

accept ヘッダなどで指定• ノード:• これにより、Web サービスのようにインタフェース
定義で表現形式が決められているのと違い、呼び側

シンとしてアクセスされるようなシステム (複数のマシンから成っていてもよい)に自由度 → 多様な呼び手を許容• サーバプロセス:□ REST/HTTP の人気←速さ、簡潔さ

OS のプロセス P で、自マシンまたは他マシンで動いているプロセスの下請けとして動くようなもの• Web サービスの SOAP では XML で表現するためパー• 意味がはっきりしているときは「サーバマシン」「サー
バプロセス」と言うかわりに単に「サーバ」と言うスが重い• XML の汎用性やインタオペラビリティは常に重要というわけではない• 単純なサービスでは JavaScript のような特定言語での操作に特化して速いのがよいかも

1.2.2

ネットワーク上で他のマシンから 1 つのマ

1.3

ATOMICITY,CONSISTENCY,
ISOLATOIN, AND DURABILITY□ トランザクションの重要な 4 つの特性

Hardware Architecture• 原子性 (atomicity) --- トランザクションは全体として実行されるかされないかのいずれか□ TP を動かすシステムの能力はさまざま• ディスプレイも文字端末、モバイル機器、廉価な PC、
ワークステーションなどさまざま• 一 貫 性 (consistency) --- ト ラ ン ザ ク ション は• フロントエンド、リクエストコントローラ、トラン• 隔離性 (isolation) --- トランザクションはそれ

ザクションサーバ、DB はどのようなサーバマシンで単独で (他のトランザクションが存在しないかのよも動かせる (小型のサーバから大型メインフレームうに) 実行まで)

データベースの内部整合性を壊さない• 耐久性 (durability) --- トランザクションの実行• 分散システムの場合、複数のマシン (1 つの部屋にある場合からキャンパス内、地域間、世界に分散まで)□ 小規模な場合:

結果は障害が発生しても失われない□ これらをまとめて ACID と呼ぶ。「ACID トランザクショ

数台のディスプレイと小型 PC の LANン」「TP システムは ACID テストを通る」。以下で順に見

接続

ていく

□ 大規模な場合 (航空予約など):

全企業、インターネッ

ト対象

1.3.1

Atomicity• ディスプレイ台数で 10 万 (端末、チケットプリンタ、 □ トランザクションは atomic (全てかゼロか): 一部分
搭乗券プリンタなど)だけが実行されるようなことがあってはいけない• ディスク台数で数千、毎秒数千トランザクション• 例:• 最大規模のネット上のシステムではユーザ数 1 億、同引き」「B に$100 追加」この両方が起きるか、両方と時使用数 1 千万なども起きないか。片方だけ起きてはならない□ このように規模に大小があるので用語の区分が必要。基

□ TP システムではこれをデータベース操作を通じて実現

本的に一般用語だが、一部はこの本固有の意味として狭• トランザクションが最後までうまく実行したとき

く定義• マシン:$100 を口座 A から B に移す --- 「A から$100(commit) はじめて効果は恒久的なものとなる

単一 OS イメージを実行しているコンピュー• 途中で失敗したら (abort) すべての変更は元に戻されるタ。1 コア、マルチコア、共有メモリ MP など。VM でもよい (他の VM とハードを共有)• サーバマシン:• システム障害が起きた場合も同様 → 整合性のある状態に戻る

クライアントや他のコンピュータのためのプログラムを実行するマシン• システム: 1 つ以上のマシンの集まりで協調して 1 □ 各ビジネス操作 (口座間の転送、座席予約、株売買):
つの機能を実現
複数のデータの更新を必要とする
7• でも人は間違える→ commit したトランザクションの効果を元に戻す別のトランザクション (補償トラ• これらをトランザクションとして原子的に実行することですべての更新がなされるか何もなされないか

ンザクション) を実行

いずれかであることを保証• 間違ってお金を転送したら、逆に同額を転送するなど
1.3.2

Handling Real-World Operations□ 完全な補償は難しい場合もある□ トランザクションは実行の過程でユーザに返す結果を生• たとえば、スプレーガンで間違った色を塗ったら(?!)、そしてその塗った位置がスプレーガンの届か成するかもないところに行ってしまっていたら (?!)• トランザクションは全てかゼロか、なので commit す• 補償トランザクションは、エラーを DB に記録し、誰かに何とかしてというメールを送ること (?!)

るまでユーザに提示したものは本当ではない (アボートしたらすべてチャラ)• 実質、どのようなトランザクションも間違って実行されることがある• トランザクションがユーザに表示したものは commit
した後でなければ使用可能でない → ユーザも注意する必要 (図 1.4)

□ だからよくできた TP システムはすべてのトランザクショ• トランザクションが commit 前にデータの一部を表示し、それをユーザが見て何かに入力してしまったンに対してそれを補償するトランザクションを持つべき

ら問題

1.3.4
□ システムによっては commit まで結果を見せないことで□ ビジネス活動によっては 1 つのトランザクションとして解決しようとしている (図 1.5)

実行しないものも• でも、commit したけれどその直後 (結果を表示する前) にクラッシュしたらどうなのか?

• 注文受け付けトランザクションはその注文を処理す

更新は実行しるトランザクションとは別のものであるのが普通たが結果は表示されていない• 具体例 (図 1.6):

Multistep Business Process• 注文の受け付け・記録は単純→すぐ OK を返せる

ATM で$100 引き出す

• 注文の処理→複数のトランザクション (与信チェック、
在庫確認、集荷、配送) を含み複雑・時間が必要• $100 を出してから commit だと、出した直後に abort
したら銀行はお金を損する• commit してから$100 出すのだと、commit 直後にク □ ビジネスプロセスが複数トランザクションであってもラッシしたらユーザはお金を損する
ユーザは原子性を欲する→補償トランザクションが必要□ いずれも「全てかゼロか」ではない…
□ 関連した問題:• 例: 注文が受け付けられても、後のトランザクショ
ンが実行不能であれば、注文受け付けの補償トラン各トランザクションが「1 回だけ」実

ザクションを実行

行されること• そのためには呼び手に「OK」を返さないといけない。
返らないと呼び手はアボートしたのかと思って再実• この場合、顧客の不満をなだめる一般的な補償トラ
ンザクション→ お詫び+無償ギフトカード (+キャンセルまたは商品到着後通知の選択)

行してしまう• しかし OK だけだと「OK が無い」ことをどう解釈すべ □ トランザクションミドルウェア → 複数ステップから成るビジネスプロセスの遂行をサポート
きか困る (commit したけれど OK を返す前にクラッシュ?)• 例: 複数ステップの遂行状況を追跡し、途中で遂行不能になったら補償トランザクションを動かすなど• 解決不能に思えるかも知れないが、永続キュー (4 章)
で解決可能

1.3.3

• より詳しくは 5 章

Compensating Transactions

1.3.5□ commit は取消不能 (commit したら abort はできない)

Consistency□ consistency(一貫性) --- トランザクションは DB の一貫性を損なわないこと8• つまり DB が一貫性のある状態でトランザクションを □ 実行が直列可能 → トランザクションに相当するリクエ
ストを発行するユーザはシステムが自分専用に動いてい開始したら、終了した時も一貫性があるるように思える• これは「内部一貫性」つまり DB 自体が持つ性質• もちろん、2 つのトランザクションを順番に実行したら、その間には他人のがはさまることはあるが…

□ DB の整合性制約として典型的には次のものがある• すべての主キーが一意的• 参照整合性:• 1 つのトランザクションについては「自分が占有」にあるフィールドに他のオブジェクトの思えるキーを保持しているなら、そのオブジェクトもきち• 実際にはもちろん「思える」だけで実は沢山並列に動いている (本当に順番だと効率が悪すぎる)んと存在している• 値の範囲の制約:

年齢が 120 未満、SSN が NULL で□ トランザクション群が直列可能であり、かつそれぞれがない、など

C を維持 →全体としてのトランザクション群も C を維持□ DB 自体ではふつう維持できないような制約もある• 各実行の結果は (直列可能により) 順番に実行しているのと同等だから• 各部門の支出がその部門の予算以下であること• 社員の給与が職位によって決まった範囲内であること□ 実際には内部でロックを使って隔離を実現 → これによ

• 社員の給与は降格されない限り減少しないこと

り多数が並行に動いても順番であるかのように見える□ AID と違い、C はトランザクションプログラムと DB と(6 章で詳しく)の共同責任• DB に整合性機能があるから直列可能は重要でない、• TP システムはトランザクションの A、I、D を保証し、これを用いてトランザクションプログラムが C を維持する (アプリの責任)という誤解があるがそれは違う• 先に述べたように、C はアプリ側がかなり責任を持つ。それをトランザクションで囲んで直列可能にす• だから ACID テストというのは厳密には言いすぎることで全体として C を維持□ TP システムから外れて実世界に関わる C もある

1.3.7 Durability• 例: DB 中の商品数が実際に棚にある商品数と一致← 物理世界での動きに依存 (正しい入庫、出庫、記 □ durability (耐久性) --- トランザクションが完了したら、その結果は安定記憶に格納されていて消えない録)(停電やシステムダウンがあっても残る)1.3.6• 安定記憶 (stable storage)、ないし nonvolatile

Isolation

storagi(不 揮 発 性 記 憶)、な い し persistentstorage(恒久記憶) → 典型的には磁気ディスクだ□ isolation (隔離) --- トランザクションを実行した
効果が、そのトランザクションだけを単独で実行した場が、最近は SSD も合と一致すること• 一旦 commit したらその後プログラムエラーやシス• こ れ を 技 術 的 用 語 で 言 え ば「 直 列 可 能(serializable)」つまり複数のトランザクション

テムダウンがあっても結果は保存されていて次に立ち上がった時にそのように修復

が「順番に 1 つずつ」実行されるのと同等• 古典的な例:□ 耐久性が重要な理由:$100 しかない口座から 2 つのトラン

ビスはユーザと企業との契約

ザクションが同時に$100 引き出してしまう• たとえば口座間である金額を移すトランザクション• その場合の結果は順番にやったのと異る (直列可能でない)• 隔離は原子性とは異る:

トランザクションが提供するサーが「完了」といったらその後で何が起ころうと金額は移動した状態 (法的合意)

原子性は「途中でやめるこ• このことを安定記憶に記録することで、エラーがあってもそこを参照して正しくするとはない」→上記の例も途中でやめていないが、結果は正しくない9• さらに「長期間残る」という意味も。当座預金に N円入っていてそれをほっておいたとして、数年後に見てもその N 円が入っているはず□ 耐久性の実現方法:

トランザクション実行時に、すべての操作をログファイルに追記していく• commit のときにはそれまでのすべての記録がログに書かれたことを確認したのちに OK の返答を返す• その後で (直後でもすこしゆっくりでも)DB 本体に書く• その途上でエラーが起きた場合も、ログを順に見てコミットされた内容が DB に既に書かれているかチェッ
クし、そうなっていなければ改めて書けばよい• 回復処理が終った後は最新の commit 後の状態になっている

10