JPH10232809A - トランザクション処理システム - Google Patents

Abstract

(57)【要約】 【課題】 トランザクション処理システムにおいて、デ
ータ管理の形態及び手法を改良することにより、データ
アクセスのオーバーヘッドを減らしスループットを高め
る。 【解決手段】 業務に使用するデータを、トランザクシ
ョンの実行履歴を格納するための追記型のログ６、頻繁
にアクセスされるが加減算しか行わないデータを格納す
るためのカウンタ７、その他の比較的複雑な構成のデー
タを格納するためのデータベース８という３種類のリソ
ースに分散して管理する。トランザクションの処理で
は、まず、ログ６に入力電文を記録し、次に、データベ
ース８の更新処理を開始し、次に、カウンタ７の更新処
理を開始し、次に、カウンタ７の更新処理をコミット
し、次に、データベース８の更新処理をコミットし、最
後に、ログ６にトランザクション実行結果を記録する。
カウンタ７の更新はコミット後も取消し可能である。カ
ウンタ７の各レコードのロック期間は各レコードを参照
し更新している期間だけに限定される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、オンラインによる
銀行業務の処理や航空券の予約・発券業務の処理のよう
なトランザクション処理のためのシステムに関する。

【０００２】

【従来の技術】例えばオンラインで銀行口座の預金や振
込を行う処理は、銀行口座の情報、入出金額、及び取引
履歴など、その取引に関連する種々のデータにアクセス
し、その内容を更新する処理から構成される。これら複
数のデータに対する処理は、全体として纏まってオンラ
イン・データベース処理の論理的単位を構成しており、
この論理的単位を「トランザクション」と呼ぶ。

【０００３】トランザクションは、それに関連する複数
のデータの内容を変化させるが、全てのデータの変化後
の内容は、互いに整合した一貫性のあるものとなってい
なくてはならない。そのため、業務に必要なデータを全
て単一のデータベースに格納することにより、一つのデ
ータベース管理システムが全てのデータを管理し、それ
らの一貫性を自動的に補償するようなトランザクション
処理システムが従来から広く利用されている。

【０００４】一方、業務に必要な複数のデータを複数の
データベースに分散させて管理するようにしたトランザ
クション処理システムも、従来から利用されている。こ
の種のシステムでは、複数のデータベース上に分散して
いるデータの一貫性を維持するために、Ｎ．Ｊ．Ｇｒａ
ｙの考案した２フェーズ・コミット方式や、３フェーズ
・コミット方式が用いられている。

【０００５】

【発明が解決しようとする課題】従来のトランザクショ
ン処理方式には次のような幾つかの問題がある。

【０００６】(1)コミット方式の問題点 データを複数のデータベース上に分散させて管理してい
るシステムでは、分散されたデータの一貫性を維持する
方式として、２フェーズ・コミット方式が広く用いられ
ている。しかし、このコミット方式では、トランザクシ
ョンのコミットフェーズにおいて、データベースマネー
ジャとトランザクションマネージャとの間で２往復の通
信処理（つまり、コミット準備の指示と応答、及びコミ
ット実行の指示と応答）を伴う同期処理を行わなくては
ならない。そのため、無視できない長さの通信オーバヘ
ッドが生じてしまい、スループットが低くなる。

【０００７】(2)データ配置の問題点 業務に使用するデータには、銀行口座情報のように複雑
な構造をもつデータ、支店コードを支店名に変換するた
めのテーブルのように参照されるだけのデータ、取引履
歴のように書き込みしか行われない追記型のデータ、入
出金金額のように加減算しかなされないデータなど、種
々のタイプのデータが存在する。従来のシステムでは、
それらのデータは（分散されているか否かに関わらず）
いずれもデータベースによって管理されている。しか
し、データベースは、複雑な構造のデータを管理するこ
とができる反面、そのための複雑な構成を備えるが故に
データアクセスオーバヘッドも大きいというマイナス面
も併せ持っている。そのため、単なるコード変換用テー
ブルや取引履歴などを格納するにはオーバヘッドが大き
過ぎ、このことも、スループット低下の一因となってい
る。

【０００８】(3)ロック期間の問題点 入出金額のようなデータはアクセス頻度が高い。このよ
うなアクセス頻度の高いデータを従来のようにデータベ
ースで管理している場合、一般にデータベースはデータ
へのアクセス開始からコミットまでデータロックを維持
するため、トランザクション期間中カウンタのロックを
保持し続けることになる。この点はシステムのボトルネ
ックとなりやす。

【０００９】従って、本発明の目的は、トランザクショ
ン処理システムにおいて、データ管理の形態及び手法を
改良することにより、データアクセスのオーバーヘッド
を減らしスループットを高めることにある。

【００１０】

【課題を解決するための手段】本発明は、トランザクシ
ョンの実行履歴を格納するためのログと、加減算しか行
わないデータを格納するためのカウンタと、業務に使用
するデータの内の前記ログ及びカウンタに格納されるデ
ータ以外のデータを格納するためのデータベースと、ト
ランザクションを要求する入力電文を受け、前記トラン
ザクションを処理するトランザクション処理手段とを備
えたトランザクション処理システムを提供する。本シス
テムでは、業務に使用するデータが、そのタイプに応じ
てログ、カウンタ及びデータベースという異なるリソー
ス上で管理される。

【００１１】本発明のトランザクション処理システムに
おいて、トランザクション処理手段は、好ましくは、
(1)入力電文を前記ログに記録する、(2)データベースを
更新するためのデータベースサブトランザクション、及
びカウンタを更新するためのカウンタサブトランザクシ
ョンを開始する、(3)カウンタサブトランザクションを
コミットする、(4)データベースサブトランザクション
をコミットする、(5)トランザクションの実行結果を前
記ログに書き込む、ことを(1)、(2)、(3)、(4)、(5)の
順序で実行することができる。

【００１２】また、カウンタは、好ましくは、カウンタ
サブトランザクションがコミットされた後でもカウンタ
の更新を取り消すための取消し手段を有することができ
る。

【００１３】さらに、本発明のシステムは、未完了のト
ランザクションのリカバリを行うためのリカバリ処理手
段を備えることができ、このリカバリ処理手段は、好ま
しくは、ログに対応する実行履歴が記録されているか否
かにより未完了トランザクションを検出し、 検出した未完了トランザクションのデータベースサ
ブトランザクションが既にコミットされているときは、
その未完了トランザクションを取引成立の状態で完了さ
せるようにログに実行結果を記録し、 他方、検出した未完了トランザクションのデータベ
ースサブトランザクションが未だコミットされていない
ときは、その未完了トランザクションを取引不成立の状
態で完了させるように、カウンタの更新を取り消すと共
にログに実行結果を記録するようにすることができる。

【００１４】本発明のシステムでは、また、トランザク
ション処理手段が、好ましくは、カウンタの各レコード
のロック期間を、各レコードにアクセスしている時のみ
に限定することできる。本発明は典型的にはコンピュー
タによって実現されるが、そのためのコンピュータプロ
グラムはディスク型ストレージ、半導体メモリ、通信ネ
ットワークなどの各種の媒体を通じてコンピュータにイ
ンストール又はロードすることができる。

【００１５】

【発明の実施の形態】以下、図面を参照して本発明の好
適な実施形態を説明する。

【００１６】１． システム構成 図１は、オンライン銀行業務処理に適した本発明の一実
施形態にかかるトランザクション処理システムのシステ
ム構成を示す。

【００１７】コンピュータ１は、業務に使用するデータ
を管理し、業務にかかるトランザクションを処理するも
ので、適用業務プログラム２と、データベース管理シス
テム３と、ＯＬＴＰ（オンライン・トランザクション処
理）パッケージ４と、オペレーティングシステム５を備
える。このコンピュータ１には、ネットワーク９を介し
て、複数の端末１０−１，１０−２，・・・，１０−ｎ
が接続されている。各端末１０−１，１０−２，・・
・，１０−ｎは、ユーザから入出金や振込のようなトラ
ンザクション処理要求を受け付けてその電文をコンピュ
ータ１へ送り、かつコンピュータ１からトランザクショ
ンの処理結果の電文を受け取ってユーザに返す。

【００１８】コンピュータ１では、業務に使用する種々
のデータが３種類のリソースに分散されて管理されてい
る。すなわち、それらデータは、取引履歴を格納するた
めのログ６、入出金額のようなアクセス頻度が高いが加
減算だけ行えばよいデータを保持したカウンタ７、その
他の口座情報のようなデータが格納されているデータベ
ース８の３種類に分類されて格納されている。ログ６は
シーケンシャルファイル、カウンタ７は加減算のみを行
うテーブル、データベース８はリレーショナル型、階層
型、又はネットワーク型などのデータベースである。

【００１９】カウンタ７は、後述する図１０及び図１１
に示すようなもので、トランザクション機能、つまり複
数のオペレーションを原子的に扱うことができる機能を
有している。さらに、カウンタ７は、トランザクション
識別子を指定して取消命令を実行することにより、一度
確定したトランザクションであっても、いつでも取り消
すことができる機能も有している。また、このカウンタ
７は、復旧処理を高速化するためのチェックポイント機
能なども備えている。

【００２０】２． リソース間でデータの同期をとるた
めに必要なデータ 図２は、本システムにおけるトランザクションの処理手
順の概要を示す。

【００２１】適用業務プログラム２が実行するトランザ
クション１１は、リソース単位のサブトランザクション
に論理的に分割される。即ち、トランザクション１１
は、データベース８のサブトランザクション１２と、カ
ウンタ７のサブトランザクション１３と、ログ６のトラ
ンザクション管理（開始／完了）１４とに論理的に分割
される。

【００２２】図３は、データベース８、カウンタ７、ロ
グ６という３種類のリソース間でデータの同期を取るた
めの管理データを示す。

【００２３】リソース間でサブトランザクションの関連
付けを行うための情報として「トランザクション識別子
（Ｔｉｄ；Ｔｒａｎｓａｃｔｉｏｎ ｉｄ）」を使用し
て、同じトランザクション１１に含まれるサブトランザ
クション１２、１３、１４間の同期処理を行う。そのた
めに、各リソース８、７、６上には、トランザクション
識別子をキーとして以下の情報を格納する。

【００２４】データベース８上には、口座情報のような
一般データの集合たるデータベース（つまり、図４のデ
ータベース２４）の他に、データベースサブトランザク
ション実行履歴表２１を設ける。データベースサブトラ
ンザクション実行履歴表２１では、何番の識別子をもつ
トランザクション１１がデータベース８に対する処理
（データベースサブトランザクション１２）を完了した
かが管理される。つまり、この表２１には、データベー
スサブトランザクション１２の完了したトランザクショ
ン１１の「トランザクション識別子」が格納される。こ
の表２１に対する更新は、データベースサブトランザク
ション１２のコミットと同期して永続化される。

【００２５】カウンタ７上には、入出金額のようなデー
タを保持した表（つまり、図４のカウンタ表２５）の他
に、カウンタサブトランザクション更新履歴表２２が設
けられる。カウンタサブトランザクション更新履歴表２
２では、何番の識別子をもつトランザクション１１がカ
ウンタ７に対する処理を完了したかが管理される。つま
り、この表２２には、カウンタ７に対する処理（カウン
タサブトランザクション１３）が完了したトランザクシ
ョン１１の「トランザクション識別子」とその処理でカ
ウンタ表２５に行った更新の「更新履歴」とが含まれ
る。この表２２に対する更新は、カウンタサブトランザ
クション１３のコミットと同期して永続化される。

【００２６】ログ６上には、トランザクション実行履歴
表２３が設けられ、ここでは、何番の識別子をもつトラ
ンザクション１１が処理を開始し、かつ完了したかを管
理がされる。つまり、この表２３には、トランザクショ
ン１１が処理を開始したときにそのトランザクション１
１の「トランザクション識別子」「入力電文」が書き込
まれ、トランザクション１１が処理を完了したときにそ
のトランザクションの「実行結果」がさらに書き込まれ
る。この表２３に対する更新は、ログ入出力要求の完了
と同期して永続化される。

【００２７】３． トランザクション処理シーケンス 図４は、コンピュータ１が行なうトランザクション処理
シーケンスを示す。

【００２８】以下、処理シーケンスを時間的順序に従っ
て説明する。

【００２９】(1)入力電文受信 端末１０から入力電文を受信する。

【００３０】(2)トランザクション識別子割り当て 次に、端末１０からの入力電文に対して、トランザクシ
ョン識別子を割り当てる。

【００３１】(3)入力電文書き込み 次に、ログ６のトランザクション実行履歴表２３に、
「トランザクション識別子」及び「入力電文」を書き込
む。こうして表２３に書き込まれた「トランザクション
識別子」及び「入力電文」は、この入力電文書き込み処
理の完了までに、ディスク記憶装置のような不揮発媒体
に格納される。

【００３２】(4)データベースの参照／更新 次に、必要に応じてデータベース８内のデータベース２
５を参照し更新する。

【００３３】(5)データベース実行履歴挿入 次に、データベース８内のトランザクション実行履歴表
２１に、トランザクション識別子を書き込む。

【００３４】(6)カウンタの参照／更新 次に、必要に応じてカウンタ７内のカウンタ表２５を参
照し更新する。カウンタ表２５の更新と同時に、カウン
タサブトランザクション更新履歴表２２に「トランザク
ション識別子」及び「更新履歴」を挿入する。こうして
更新されたカウンタサブトランザクション更新履歴表２
２は、カウンタサブトランザクション１３のコミット完
了までに不揮発媒体に格納されればよく、このカウンタ
参照／更新処理の時点では未だ不揮発媒体に格納されて
いる必要はない。また、カウンタ表２５のデータに対し
て行うことができるオペレーションは加減算のみに限定
されているため、カウンタ表２５のロックはカウンタサ
ブトランザクション１３のコミット時まで保持しておく
必要はない。従って、カウンタ表２５の各レコードのロ
ック期間はそのレコードの参照／更新中のみに限定され
る。

【００３５】(7)カウンタサブトランザクションコミッ
ト 次に、カウンタ７に対してカウンタサブトランザクショ
ン１３のコミットを宣言する。このカウンタサブトラン
ザクション１３のコミット完了までに、当該カウンタサ
ブトランザクション１３の「更新履歴」（つまり、(6)
の処理で更新履歴表２２に書き込んだ「更新履歴」）が
不揮発媒体に格納される。

【００３６】(8)データベースサブトランザクションコ
ミット 次に、データベース８に対してデータベースサブトラン
ザクション１２のコミットを宣言する。このデータベー
スサブトランザクション１２のコミット完了までに、当
該データベースサブトランザクション１２の「実行履
歴」（つまり、(5)の処理で実行履歴表２１に書き込ん
だ「トランザクション識別子」）が不揮発媒体に格納さ
れる。

【００３７】(9)トランザクション実行結果書き込み 次に、ログ６のトランザクション実行履歴表２３に、ト
ランザクション実行結果（取引の「成立」又は「不成
立」）を書き込む。こうして書き込まれた当該トランザ
クション１１のトランザクション実行結果は、このトラ
ンザクション実行結果書き込み処理の完了までに、不揮
発媒体に格納される。

【００３８】(10)出力電文送信 最後に、端末１０に対して、出力電文を送信する。

【００３９】図５は、上述したシーケンスにおける(6)
及び(7)のカウンタ処理を詳細に示している。

【００４０】初期状態では、例えばカウンタ表２５の
「１」番の支店の金額は「０」であり、また、カウンタ
サブトランザクション更新履歴表２２にはデータが無か
ったとする。この状態において、Ｔｉｄが「１」番で、
「１」番の支店に金額「１００」を入金するようなトラ
ンザクションが発生したとする。すると、このトランザ
クションのカウンタ更新処理及びカウンタコミット処理
は、以下の手順で行われる。

【００４１】(1)カウンタ更新処理では、まず、カウン
タ表２５の支店「１」のレコードの更新ロックを獲得す
る。

【００４２】(2)次に、更新履歴表２２に、Ｔｉｄ
「１」と、更新履歴「支店＝１、金額＋＝１００」を書
き込む。

【００４３】(3)次に、カウンタ表２５の支店「１」の
レコードの金額に「１００」を加算する。

【００４４】(4)次に、カウンタ表２５の支店「１」の
レコードの更新ロックを解除する。これでカウンタ更新
処理が終了する。

【００４５】(5)続くカウンタコミット処理では、更新
履歴表２２のＴｉｄ「１」のレコードをディスク記憶装
置３１のような不揮発性媒体に書き込む。

【００４６】４． リカバリ処理シーケンス 図６は、完全にコミットされたトランザクション（以
下、完了トランザクションという）、及び処理途中での
異常発生により完全にはコミットできなかったトランザ
クション（以下、未完了トランザクションという）の例
を示す。

【００４７】トランザクションＴ１及びＴ２は完了トラ
ンザクションを示し、そのうちＴ１は取引が「成立」し
たもの、Ｔ２は処理途中でロールバックされて取引が
「不成立」となったものを示す。トランザクションＴ３
〜Ｔ６は、異常が発生した処理段階の異なる幾つかの未
完了トランザクションの例を示す。

【００４８】図７は取引「成立」の未完了トランザクシ
ョンのリカバリ処理シーケンスを示し、図８は取引「不
成立」の未完了トランザクションのリカバリ処理シーケ
ンスを示す。

【００４９】以下、図７及び図８に示すリカバリ処理シ
ーケンスを時間的順序に沿って説明する。

【００５０】(1)未完了トランザクション抽出 不揮発性媒体（ディスク）３１内のログ６のトランザク
ション実行履歴表２３を調べることにより、未完了トラ
ンザクション（つまり、実行履歴表２３に未だトランザ
クション実行結果が書き込まれていないトランザクショ
ン）のＴｉｄを抽出する。

【００５１】例えば、図９に示すようにトランザクショ
ン実行履歴表２３が記録されていた場合、Ｔｉｄ＝１及
び２のトランザクションは完了トランザクションである
が、Ｔｉｄ＝３〜６のトランザクションは未完了トラン
ザクションである。従って、Ｔｉｄ＝３〜６のトランザ
クションがリカバリ処理の対象となる。

【００５２】(2)未完了データベースサブトランザクシ
ョン抽出 次に、不揮発性媒体（ディスク）３１内のデータベース
８のトランザクション実行履歴表２１を調べ、各未完了
トランザクションについてのデータベースサブトランザ
クション１２の完了／未完了を調べる。そして、データ
ベースサブトランザクション１２が完了しているトラン
ザクションのみを「取引成立」とし、データベースサブ
トランザクション１２が未完了なものを「取引不成立」
とすることにより、各未完了トランザクションについて
「取引成立」か「取引不成立」かを判断する。

【００５３】例えば、図１０に示すようにデータベース
サブトランザクション実行履歴表２１が記録されていた
場合、Ｔｉｄ＝１〜３のトランザクションはデータベー
スサブトランザクション１２が完了しているから「取引
成立」であり、Ｔｉｄ＝４〜６のトランザクションはデ
ータベースサブトランザクション１２が未完了であるか
ら「取引不成立」である。

【００５４】従って、図９の例で抽出されたＴｉｄ＝３
〜６の未完了トランザクションのうち、Ｔｉｄ＝３は
「取引成立」、Ｔｉｄ＝４〜６は「取引不成立」と判断
される。

【００５５】これ以降の処理は、「取引成立」か「取引
不成立」かに応じて２種類に分かれる。

【００５６】(3)取引成立時（図７） 「取引成立」と判断した未完了トランザクションについ
ては、データベース８の処理が完了しているから、当該
トランザクションは実質的に完了したものとみなして、
ログ６のトランザクション実行履歴表２３のトランザク
ション実行結果欄に「取引成立」と書き込む。この場
合、データベースサブトランザクション及びカウンタサ
ブトランザクションはコミットされているから、データ
ベース８及びカウンタ７に対するリカバリ処理は不要で
ある。これで、リカバリ処理が終わる。

【００５７】(4)取引不成立時（図８） 「取引不成立」と判断した未完了トランザクションにつ
いては、データベース８の処理が完了していないから、
当該トランザクションは実質的にロールバックされたも
のとみなして、 まず、カウンタ７において、該当Ｔｉｄのカウンタ
サブトランザクション１３の取り消しを行い、 次に、ログ６のトランザクション実行履歴表２３中
のトランザクション実行結果の欄に「取引不成立」と書
き込む。この場合、データベース８は当該トランザクシ
ョン発生前の状態のままであるから、データベース８に
対するリカバリ不要である。これで、リカバリ処理が終
わる。

【００５８】図１１は、上記リカバリ処理における(4)
の取引不成立時ののカウンタ取り消し処理の詳細を示
す。以下、このカウンタ取り消し処理を時間順に沿って
説明する。

【００５９】ここで、初期状態として、カウンタ表２５
には支店「１」、金額「１００」と記録され、更新履歴
表２２にはＴｉｄ「１」、更新履歴「支店＝１、金額＋
＝１００」と記録されていたとする。また、リカバリ対
象はＴｉｄ＝１のトランザクションであるとする。取消
し処理は以下の手順で行われる。

【００６０】(1)まず、カウンタ７の更新履歴表２２か
らＴｉｄ＝１の更新履歴を検索する。

【００６１】(2)次に、Ｔｉｄ＝１のトランザクション
がアクセスしたカウンタ表２５内のレコード（ここで
は、支店＝１のレコード）の更新ロックを獲得する。

【００６２】(3)次に、カウンタ表２５の支店＝１のレ
コードに対して、Ｔｉｄ＝１のトランザクションが行っ
た更新の打消処理（逆オペレーション、つまり、金額
「−１００」の加算）を行ない、金額を「０」に戻す。

【００６３】(4)次に、更新履歴表２２のＴｉｄ＝１の
レコードに「取消」を記入する。

【００６４】(5)次に、ディスク３１中のカウンタの更
新履歴表２２のＴｉｄ＝１のレコードにも「取消」を記
入する。

【００６５】(6)次に、Ｔｉｄ＝１のトランザクション
がアクセスしたレコード（支店＝１のレコード）の更新
ロックを開放する。これで、取消し処理が終了する。

【００６６】５． 実施形態の利点 以上説明した実施形態について、コミット方式、データ
配置、ロック期間という３つの観点からの利点を以下に
述べる。

【００６７】(1)コミット方式 本実施形態では、複数のリソースに分散されている複数
のデータに対するアクセス順序に一定の制約を設けてい
る。すなわち、図４に示したように、まずログ６に入力
電文を記録し、次に、カウンタ７の更新処理をコミット
し、次に、データベース８の更新処理をコミットし、最
後にログ６に実行結果を記録する、という順序を採用す
る。また、トランザクション機能を有するカウンタ７
に、取消処理機能を持たせており、この取消処理はコミ
ット後であっても行えるようにしてある。結果として、
２フェーズコミット方式を用いなくても、全てのデータ
の一貫性を維持することができる。その理由は次の通り
である。

【００６８】 トランザクションの実行結果はトラン
ザクションの最後にログ６に記録されるから、この実行
結果の有無により、どのトランザクションが未完了であ
るかを知ることできる。

【００６９】 入力電文はトランザクションの最初に
ログ６に記録されるから、未完了のトランザクションを
完了させるようにリカバリする場合、その最初に記録さ
れた入力電文に基づいてリカバリを行うことができる。

【００７０】 データベースの更新処理のコミットは
カウンタの更新処理のコミットの後で行われ、かつカウ
ンタの更新はそのコミット後も取り消せるから、データ
ベースの更新処理が未完了のトランザクションについて
は、リカバリ処理でカウンタの更新を取り消すことによ
って、ロールバックされたと同様な状態へ戻すことがで
きる。また、データベースの更新処理が完了している未
完了トランザクションについては、リカバリ処理でログ
６に実行結果を記録するだけで、完了した状態にするこ
とができる。

【００７１】このように、２フェーズコミット方式が不
要となることにより、２フェーズコミット方式に比べて
リソース間の同期方式を単純化し、高速化することがで
きる。

【００７２】(2)データ配置 既に述べたように、業務で使用するデータには様々なタ
イプがあり、例えば顧客の口座残高を格納する表のよう
に参照及び更新を行うものもあれば、支店コードを支店
名に変換するときに使用するような参照しか行わない表
や、取引の履歴を記録しておくために追加型の書き込み
しか行わないものなど、データのタイプにより、その取
り扱い方法も様々である。本実施形態では、このような
種々のタイプのデータをデータベース、カウンタ、ログ
など、それぞれのデータの性格に応じた最適なリソース
に分散させて配置している。換言すれば、全てのデータ
をデータベースに格納しているのではない。そのため、
システムのオーバヘッドが減少し、レスポンスタイムや
スループットが改善される。

【００７３】(3)ロック期間 カウンタのように、他のデータとの一貫性が必要で、頻
繁にアクセスされるが加減算しか行わないようなデータ
へアクセスする際のデータロック期間を、データへのア
クセスを開始してからコミットする迄ではなく、データ
アクセス時（メモリ上のデータを参照／更新している期
間）のみに限定している。それにより、これらのデータ
へアクセスする際の同時実行性が高まる。

【００７４】尚、本発明を実施するためのマシン可読の
コンピュータプログラムは、ディスク型ストレージや半
導体メモリのような固定的にプログラムを担持する媒体
や、通信ネットワークの様な流動的にプログラムを担持
する媒体から、コンピュータに供給することができる。

【図面の簡単な説明】

【図１】本発明の一実施形態にかかるトランザクション
処理システムのシステム構成を示すブロック図。

【図２】トランザクションとサブトランザクションの関
係を示す説明図。

【図３】リソース間でデータの同期をとるための管理デ
ータを示す説明図。

【図４】トランザクション処理シーケンスの説明図。

【図５】カウンタの処理方式の説明図。

【図６】トランザクションの例を示す説明図。

【図７】取引成立時のリカバリ処理シーケンスの説明
図。

【図８】取引不成立時のリカバリ処理シーケンスの説明
図。

【図９】ログのトランザクション実行履歴表の記録例を
示す説明図。

【図１０】データベースサブトランザクション実行履歴
表の記録例を示す説明図。

【図１１】カウンタの取消処理方式の説明図。

【符号の説明】

１ コンピュータ ２ 適用業務プログラム ３ データベース管理システム ４ ＯＬＴＰパッケージ ５ オペレーティングシステム ６ ログ ７ カウンタ ８ データベース

Claims (6)

【特許請求の範囲】
1. 【請求項１】 トランザクションの実行履歴を格納する
   ためのログと、 加減算しか行わないデータを格納するためのカウンタ
   と、 業務に使用するデータの内の前記ログ及びカウンタに格
   納されるデータ以外のデータを格納するためのデータベ
   ースと、 トランザクションを要求する入力電文を受け、前記トラ
   ンザクションを処理するトランザクション処理手段とを
   備えたトランザクション処理システム。
2. 【請求項２】 請求項１記載のものにおいて、前記トラ
   ンザクション処理手段が、 (1)前記入力電文を前記ログに記録する、 (2)前記データベースを更新するためのデータベースサ
   ブトランザクション、及び前記カウンタを更新するため
   のカウンタサブトランザクションを開始する、 (3)前記カウンタサブトランザクションをコミットす
   る、 (4)前記データベースサブトランザクションをコミット
   する、 (5)前記トランザクションの実行結果を前記ログに書き
   込む、ことを(1)、(2)、(3)、(4)、(5)の順序で実行す
   るトランザクション処理システム。
3. 【請求項３】 請求項２記載のものにおいて、前記カウ
   ンタが、前記カウンタサブトランザクションがコミット
   された後に前記カウンタの更新を取り消すための取消し
   手段を有するトランザクション処理システム。
4. 【請求項４】 請求項３記載のものにおいて、未完了の
   トランザクションのリカバリを行うためのリカバリ処理
   手段をさらに備え、 前記リカバリ処理手段は、前記ログに対応する実行履歴
   が記録されているか否かにより未完了トランザクション
   を検出し、 検出した前記未完了トランザクションのデータベー
   スサブトランザクションが既にコミットされているとき
   は、前記未完了トランザクションを取引成立の状態で完
   了させるように前記ログに実行結果を記録し、 検出した前記未完了トランザクションのデータベー
   スサブトランザクションが未だコミットされていないと
   きは、前記未完了トランザクションを取引不成立の状態
   で完了させるように、前記カウンタの更新を取り消すと
   共に前記ログに実行結果を記録するトランザクション処
   理システム。
5. 【請求項５】 請求項１記載のものにおいて、前記トラ
   ンザクション処理手段が、前記カウンタの各レコードの
   ロック期間を、前記各レコードにアクセスしている時の
   みに限定するトランザクション処理システム。
6. 【請求項６】 トランザクションの実行履歴を格納する
   ためのログと、 加減算しか行わないデータを格納するためのカウンタ
   と、 業務に使用するデータの内の前記ログ及びカウンタに格
   納されるデータ以外のデータを格納するためのデータベ
   ースと、 トランザクションを要求する入力電文を受け、前記トラ
   ンザクションを処理するトランザクション処理手段とを
   備えたトランザクション処理システムとしてコンピュー
   タを機能させるためのプログラムを担持したコンピュー
   タ読取り可能な記録媒体。