JP4237354B2 - トランザクション処理方法及びトランザクション処理システム - Google Patents
トランザクション処理方法及びトランザクション処理システム Download PDFInfo
- Publication number
- JP4237354B2 JP4237354B2 JP27626499A JP27626499A JP4237354B2 JP 4237354 B2 JP4237354 B2 JP 4237354B2 JP 27626499 A JP27626499 A JP 27626499A JP 27626499 A JP27626499 A JP 27626499A JP 4237354 B2 JP4237354 B2 JP 4237354B2
- Authority
- JP
- Japan
- Prior art keywords
- file
- transaction
- update
- updated
- transactions
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/466—Transaction processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/1865—Transactional file systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99943—Generating database or data structure, e.g. via user interface
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99944—Object-oriented database structure
- Y10S707/99945—Object-oriented database structure processing
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Computer Hardware Design (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、複数のトランザクションが並行して同じファイルにアクセスするトランザクション処理方法及びトランザクション処理システムに関する。
【０００２】
【従来の技術】
一般に、トランザクション処理システムにおいては、トランザクションと呼ぶ処理の流れを単位として処理の実行を管理する。例えば、端末装置やネットワークなどから受け取った処理要求に対して、必要な処理を実行し、その結果を返すような、何らかの手段で起動された処理を実行する流れをトランザクションと呼ぶ。個々のトランザクションは、実行過程で、１または複数のファイル（あるいはデータベース）に記録管理するデータの更新を行う。トランザクション処理システムは、このような１または複数のデータの更新を、アトミックにコミットするかアボートするかのいずれかの状態にすることを保証する。すなわち、すべての更新を同時に有効にするのがコミットである。逆に、すべての更新を捨ててトランザクションを実行しなかったのと同じ状態に戻すのがアボートである。また、トランザクション処理システムは、一度トランザクションをコミットしたら、そのトランザクションによる更新が取り消されることがないことも保証する。
【０００３】
このようなトランザクション処理システムを実現する方式は広く知られており、例えば“ＴＲＡＮＳＡＣＴＩＯＮ ＰＲＯＣＥＳＳＩＮＧ： ＣＯＮＣＥＰＴＳ ＡＮＤ ＴＥＣＨＮＩＱＵＥＳ”（Ｊｉｍ Ｇｒａｙ，Ａｎｄｒｅａｓ Ｒｅｕｔｅｒ著、Ｍｏｒｇａｎ Ｋａｕｆｍａｎｎ）にはさまざまな方式が開示されている。
【０００４】
トランザクション処理システムにおいて扱いが難しいのは、１つのファイル上のデータを、同時に複数のトランザクションが更新する場合である。１つのファイルには同時に１つのトランザクションしか更新することを許さなければ問題は生じない。しかし、同時に複数のトランザクションを並行に処理して性能を向上させるためには、同時に１つのファイルの中の異なる部分に記録管理するデータを更新できるようにすることが必要になる。この問題は、ファイルではなくデータベースを用いる場合も同様である。以下、ファイルを例に説明するが、データベースにおいても同様である。
【０００５】
このような並行に更新処理を行うトランザクション処理システムを実現するために従来から広く用いられているのは、ＷＡＬ（Ｗｒｉｔｅ Ａｈｅａｄ Ｌｏｇｇｉｎｇ）と呼ばれる方式である。この方式は、メモリ上のバッファに読み込んだファイルに対し、複数のトランザクションが更新を行った場合、ログファイルにはどのトランザクションがどのファイルのどの部分をどう書き換えたかを記録する。さらに、ログに記録した更新情報が安定記憶装置（例えばハードディスク）上に書かれて消えないことが保証されるまで、バッファ上で行った更新はハードディスクなどの記憶媒体上の元のファイルには書き戻さないようにタイミングを制御する。
【０００６】
ＷＡＬ方式ではすべての更新履歴はログに記録されており、システムの障害が発生した場合には、そのログを使ってファイルを正しい状態に戻すことができる。すなわち、障害が発生してシステムを再起動した場合、トランザクション処理システムはログを見て、コミットしたトランザクションが行った更新で、それがファイルに反映されていないものは正しく反映させる。また、アボートしたトランザクションによる更新がファイルに書きこまれていたらそれを取り消す処理を行う。このようなリカバリ処理により、障害発生に対してもトランザクションの原子性（Ａｔｏｍｉｃｉｔｙ）や耐久性（Ｄｕｒａｂｉｌｉｔｙ）や分離性（Ｉｓｏｌａｔｉｏｎ）や一貫性（Ｃｏｎｓｉｓｔｅｎｃｙ）を保証することができる。
【０００７】
トランザクション処理システムを実現するもう１つの方式は、シャドウページ方式である。この方式でファイルを更新する場合には、ハードディスク上に、更新前のファイルが書き込まれているページと、更新後のファイルが書き込まれているページの両方を用意し、トランザクションのコミット時にファイルの管理データをアトミックに入れ替える。そのため、常にハードディスク上には正しいファイルが存在することが保証できる。
【０００８】
【発明が解決しようとする課題】
従来のＷＡＬ方式によるトランザクション処理方式では、トランザクションがファイルを更新する場合、まず更新内容をログに書いてからファイル本体を更新するため、複数のトランザクションによるファイルの共有を管理するためには複雑な処理手順を必要とする。また、１回の更新に対して、ログとファイル本体への２回の書き込み処理が必要になる。また、リカバリに必要な更新情報をログに記録し、リカバリ時にそのログを使ってファイルを一貫性のある状態に戻す処理は、複雑な処理手順を必要とする。さらに、リカバリ処理は障害発生後の再起動時に集中して行わなければならず、再起動に時間がかかるという問題点がある。
【０００９】
一方、シャドウページ方式では、ハードディスク上には常に正しい状態のファイルが存在するので、障害発生時のリカバリ処理のオーバヘッドが小さいという特徴を持つ。しかし、シャドウページ方式は、１つのトランザクションのコミット前とコミット後の２つのファイルのデータが記録されたページを、アトミックに交換することを基本操作としている。そのため、複数のトランザクションが同じファイルを更新したい場合には、それらのトランザクションをシリアライズして順に更新して行くようにしなければならない。ＷＡＬ方式のように同じファイルの異なる部分を複数のトランザクションが並行して更新できるようにするためにはシャドウページ方式だけでは無理で、その上にＷＡＬ方式と同じようにログを使ったデータの管理をするなどの工夫が必要になる。そのため、シャドウページ方式は簡単に実装できても、その上に複雑なデータの管理を実装することが必要になるという問題点がある。
【００１０】
本発明は、上記事情を考慮してなされたもので、並行に動作する複数のトランザクションによるファイルの更新処理と障害時のリカバリ処理を簡単に効率良く実現することのできるトランザクション処理方法及びトランザクション処理システムを提供することを目的とする。
【００１１】
【課題を解決するための手段】
本発明は、各トランザクションがそれぞれ１以上のファイルを更新対象とするトランザクション処理システムのトランザクション処理方法であって、複数のトランザクションが同時に更新対象としているファイルの各々について、当該ファイルのファイル識別情報と当該ファイルを同時に更新対象としている複数のトランザクションのトランザクション識別情報との対応を記録した第１の管理表を記憶する第１のステップと、一つのトランザクションが占有して更新対象としているファイルの各々について、当該ファイルのファイル識別情報と当該ファイルを更新対象としている一つのトランザクションのトランザクション識別情報との対応を記録した第２の管理表を記憶する第２のステップと、複数のトランザクションが同時に更新対象としているファイルごとに、それぞれ、安定記憶装置からバッファ領域上に読み出した同一のファイルを更新対象として複数のトランザクションが処理を行う第３のステップと、前記複数のトランザクションのうちの一つのトランザクションのコミット時に、当該一つのトランザクションのトランザクション識別情報に基づき前記第１の管理表を参照して、当該一つのトランザクションが同時に更新対象としているファイルのファイル識別情報を求め、求めたファイル識別情報に係るファイルそれぞれについて、当該一つのコミットするトランザクションによる確定した更新内容と、他のコミットしていないトランザクションによる未確定の更新内容と、該未確定の更新を取り消すための情報とをファイル内容として含む前記ファイルを、安定記憶装置に書き込むことを、同期して行う第４のステップとを有し、前記第４のステップにおいては、更に、前記一つのトランザクションのトランザクション識別情報に基づき前記第２の管理表を参照し、当該一つのトランザクションが前記ファイルとは別のファイルを占有して更新対象として前記バッファ領域上で処理を行っていた場合には、前記ファイルの前記安定記憶装置への書き込みと同期させて、当該一つのトランザクションによる前記別のファイルに対する確定した更新内容をファイル内容として含む前記別のファイルを前記安定記憶装置に書き込むことを特徴とする。
【００１２】
安定記憶装置とは、例えば、ハードディスク等の、電源を切っても記憶した内容が消えない記憶装置を指す。
【００１３】
本発明では、上記のように、あるトランザクションのコミット時に、そのトランザクションが更新したファイルを別のトランザクションも更新している場合には、その別のトランザクションによる更新内容とそれを取り消すための情報も一緒にファイルの中身に書き込んで、そのファイルを安定記憶装置（例えばハードディスク）に書き出すことにより、ファイルとは別にログを用意して複雑な管理を行うようなことをしなくとも、トランザクションの原子性（トランザクション単位で、行った更新の全てが安定記憶装置上で有効になる（コミット）か全て無効になる（アボート）かいずれかの状態にしかならないことを、システムに障害が起きた場合でも保証できること）を担保しつつ、一つのファイルのデータを複数のトランザクションが並行して更新することを実現できる。
【００１４】
好ましくは、前記他のコミットしていないトランザクションをコミットする時には、該他のこれからコミットするトランザクションによる新たに確定した更新内容と、以前にコミットしたトランザクションによる既に確定している更新内容のうち該他のこれからコミットするトランザクションによる新たに確定した更新内容とは競合しないものとをファイル内容として含むファイルを、前記安定記憶装置に格納された前記ファイルに上書きするようにしてもよい。
【００１５】
あるトランザクションがコミットした後、同じファイルを更新している別のトランザクションをコミットする場合には、後にコミットするトランザクションの更新内容と、先にコミットしたトランザクションの更新内容のうち後にコミットするトランザクションによって書き換えられてはいないものとを書き込んだファイルで、先に安定記憶装置に書き出されたファイル（後にコミットすることになるトランザクションの更新内容とそれを取り消すための情報が入っている）を上書きすれば、トランザクションの原子性を担保できる。なお、あるトランザクションがコミットした後、同じファイルを更新している別のトランザクションをアボートする場合には、アボートするトランザクションによる更新がなかった状態に戻したファイルで、先に安定記憶装置に書き出されたファイル（後にアボートすることになるトランザクションの更新内容とそれを取り消すための情報が入っている）を上書きしても良いし、アボート時には何もしなくとも、下記のように次にファイルを読み出す時にリカバリ処理を行えば、トランザクションの原子性は担保できる。
【００１６】
好ましくは、新しくファイルを前記安定記憶装置から読み出した時に、このファイルに、コミットしていないトランザクションによる未確定の更新内容および該未確定の更新を取り消すための情報が含まれているか否かを調べ、含まれている場合には、読み出した前記ファイルを前記情報を用いて前記コミットしていないトランザクションによる更新がなかった状態に戻すようにしてもよい。
【００１７】
あるトランザクションがコミットした後、同じファイルを更新している別のトランザクションのコミット／アボートが行われる前に、システムに障害が起きた場合でも、コミットしたトランザクションによる更新は既に安定記憶装置上でファイルに正しく反映されている。これに加えて上記のようなリカバリ処理を行えば、未確定の（別の）トランザクションによる更新はアボートしたものとしてそれを取り消すことができるので、トランザクションの一貫性が保たれる。しかも、このリカバリ処理は、障害回復時に行う必要はなく、次にそのファイルを読み出した時に行えば良い。
【００１８】
好ましくは、前記一つのコミットするトランザクションが前記ファイルとは別のファイルをも更新対象として前記バッファ領域上で処理を行っていた場合には、前記ファイルの前記安定記憶装置への書き込みと同期させて、該一つのコミットするトランザクションによる前記別のファイルに対する確定した更新内容をファイル内容として含む前記別のファイルを前記安定記憶装置に書き込むようにしてもよい。
【００１９】
上記のように複数のファイルの書き込みを同期させれば、一つのトランザクションがその処理開始時からコミット時までに複数のファイルに対して行った更新の全てが安定記憶装置上で有効になる（コミット）か、全てが無効になる（アボート）か、いずれかの状態にしかならない（システムに障害が起きた場合でも、一つのトランザクションが行った更新のうち一部分だけが有効になり残りが無効になるということはあり得ない）ことを保証するような、アトミックな書き込みが実現できる。
【００２０】
好ましくは、前記ファイルは、一纏まりの情報を分割して記録した複数個のファイルの集合の中の一つのファイルであるようにしてもよい。
【００２１】
好ましくは、一纏まりの情報を分割して記録した複数個のファイルの集合に対して二つ以上のトランザクションが前記バッファ領域上で更新を行い、この二つ以上のトランザクションによる更新内容に基づいて、前記バッファ領域上で、新しいファイルの追加、ファイル間の情報の移動および不要ファイルの削除のうち少なくとも一つを行うことにより、前記複数個のファイルそれぞれの大きさが予め定められた基準に従うように調整し、前記一つのコミットするトランザクションが更新したファイル、および該トランザクションによる更新に伴う前記調整の結果更新あるいは新規に作成されたファイルのうち、少なくとも一つのファイルに対して他のトランザクションが更新を行っている場合には、該少なくとも一つのファイルを更新対象（すなわち前記ファイル）として複数のトランザクションが処理を行ったものとして、前記ファイルの前記安定記憶装置への書き込みを行うようにしてもよい。
【００２２】
また、本発明は、各トランザクションがそれぞれ１以上のファイルを更新対象とするトランザクション処理システムであって、複数のトランザクションが同時に更新対象としているファイルの各々について、当該ファイルのファイル識別情報と当該ファイルを同時に更新対象としている複数のトランザクションのトランザクション識別情報との対応を記録した第１の管理表を記憶する手段と、一つのトランザクションが占有して更新対象としているファイルの各々について、当該ファイルのファイル識別情報と当該ファイルを更新対象としている一つのトランザクションのトランザクション識別情報との対応を記録した第２の管理表を記憶する手段と、複数のトランザクションが同時に更新対象としているファイルを、それぞれ、安定記憶装置からバッファ領域上に読み出す手段と、複数のトランザクションが同時に更新対象としているファイルごとに、それぞれ、当該ファイルに対して複数のトランザクションのそれぞれが行った更新の内容と該更新を取り消すための情報とを前記バッファ領域上で該ファイル内に書き込む手段と、前記複数のトランザクションのうちの一つのトランザクションのコミット時に、当該一つのトランザクションのトランザクション識別情報に基づき前記第１の管理表を参照して、当該一つのトランザクションが同時に更新対象としているファイルのファイル識別情報を求め、求めたファイル識別情報に係るファイルそれぞれについて、当該ファイル内に書き込まれた該一つのコミットするトランザクションによる更新の内容については該更新を取り消すための情報を削除することにより確定させ、前記ファイル内に書き込まれた他のコミットしていないトランザクションによる更新の内容および該更新を取り消すための情報についてはそのままとし、確定させた内容とそのままとした情報とをファイル内容として含む前記ファイルを、前記安定記憶装置に書き出すことを、同期して行う制御手段とを備え、前記制御手段は、前記一つのトランザクションが前記ファイルとは別のファイルを占有して更新対象として前記バッファ領域上で処理を行っていた場合には、前記ファイルの前記安定記憶装置への書き込みと同期させて、当該一つのトランザクションによる前記別のファイルに対する確定した更新内容をファイル内容として含む前記別のファイルを前記安定記憶装置に書き込むことを特徴とする。
【００２４】
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
【００２５】
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。
【００２６】
本発明によれば、並行に動作する複数のトランザクションによるファイルの更新を、簡単な処理手順で実現することができる。本発明によれば、従来のＷＡＬ方式や、シャドウページ方式の上に特殊なログ管理を実装するときのように、データの更新時やコミット処理時あるいはリカバリ時に複雑な処理を必要としない。
【００２７】
また、本発明では、障害発生後のリカバリ処理を、再起動時に集中して行う必要は無く、障害で更新途中の状態は次にそのファイルを使う時点で行われるため、リカバリ処理のオーバヘッドが小さい。
【００２８】
さらに、本発明では、１つのデータを複数のファイルに分けて管理することで、ファイルの更新のコミット時にディスクに書き戻すデータの量を減らすことができる。
【００２９】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【００３０】
最初に従来のファイルシステムについて簡単に説明する。図４３に、従来のトランザクション処理システムの例を示す。従来のトランザクション処理システムでは、トランザクションを処理するアプリケーションプログラム１０１は、データベース管理システム１０２を介してデータの操作を行う。ファイルシステム１０３はハードディスク１０４などの安定記憶装置に記録したファイルの操作や管理を行う。データベース管理システム１０２は、ファイルシステム１０３の管理するファイルを使って、アプリケーションプログラム１０１が必要とするデータを管理する。複数のアプリケーションプログラム１０１が共有しているデータに対する操作の間の並行制御もデータベース管理システム１０２が行う。
【００３１】
図１に、本発明の一実施形態に係るトランザクション処理システムの構成例を示す。
【００３２】
なお、本実施形態では、安定記憶装置としてハードディスクを用いるものとして説明するが、もちろん安定記憶装置として他の装置を使用することも可能である。また、本実施形態では、ユーザプログラムによりトランザクションが発生するものとして説明するが、もちろんユーザプログラム以外のものがトランザクションを発生させる場合も同様である。
【００３３】
本実施形態のトランザクション処理システムでは、図１に示されるように、トランザクションを実行する複数のアプリケーションプログラム２間で共有するファイルの操作は、共有データ管理部４を介して行い、共有しないファイルの操作は、アプリケーションプログラム２がファイルシステム６を直接指示して行う。
【００３４】
トランザクションマネージャ８は、各アプリケーションプログラム２が処理するトランザクションの管理を行う。アプリケーションプログラム２は、トランザクションの処理を開始する時点で、トランザクションマネージャ８からトランザクション識別子を割り付けてもらう。以降、トランザクションの処理を進めて行く過程で、共有データ管理部４やファイルシステム６に操作を指示するときには、トランザクション識別子を提示してどのトランザクションによるファイルの更新であるかを知らせる。アプリケーションプログラム２がトランザクションの処理の終了をトランザクションマネージャ８に伝えると、トランザクションマネージャ８は共有データ管理部４やファイルシステム６に対して、トランザクション識別子で指定したトランザクションによるファイルの更新結果をハードディスク１０に書き込んでコミットするか、あるいは更新結果を廃棄してアボートするかを指示する。
【００３５】
なお、トランザクションマネージャ８を用いず、ユーザプログラム２が自分でトランザクション識別子に相当する情報を生成したり、コミット（ＣＯＭＭＩＴ）やアボート（ＡＢＯＲＴ）を指示するように実施することもできる（本実施形態では、トランザクションマネージャ８を用いる場合について説明する）。
【００３６】
共有データ管理部４は、複数のトランザクションによる同一ファイルの異なる部分の更新を実現する。共有データ管理部４は、（当該共有データ管理部４を介して）どのファイルがどのトランザクションによって更新されているかを、更新管理表４１を用いて管理している。図２に、更新管理表４１の例を示す。更新管理表４１には、ファイル名と、そのファイルを更新中のトランザクションのトランザクション識別子のリストの対応が記録されている。図２では、例えば、Ｆ０１０２というファイルはトランザクション識別子が３６，２１，５の３つのトランザクションによって更新中であることを示している。
【００３７】
ファイルシステム６は、トランザクションによるファイルの操作を実現する部分である。ファイルシステム６は、バッファ領域６２を管理するバッファ管理部（図示せず）とトランザクション管理表６１を持っている。ハードディスク１０に記録しているファイルを読んだり更新したりする場合には、そのファイルをバッファ領域６２に読み出してきて、バッファ領域６２上で読んだり更新したりする。新しくファイルを作成する場合には、まずバッファ領域６２にファイルを作成する。バッファ領域６２上で更新や作成されたファイルは、トランザクションのコミット時にハードディスク１０に書き込む。トランザクション管理表６１は、どのトランザクションがどのファイルを更新しているかを管理している。
【００３８】
図３に、トランザクション管理表６１の例を示す。トランザクション管理表６１には、トランザクション識別子と、そのトランザクションが更新中のファイルのリストの対応が記録されている。図３の例では、トランザクション識別子“３”のトランザクションはファイルＦ９２６８のみを更新しており、トランザクション識別子“５”のトランザクションはファイルＦ０１００とＦ９２６４の２つのファイルを更新していることを示している。トランザクション管理表６１の最後のエントリは、どのトランザクションにも属していないファイルの更新を管理している。
【００３９】
図３に例示したトランザクション管理表６１では、最後の行のトランザクション“ＮＯＴＸ”のエントリがこれに当たる。この例では、ファイルＦ０１０２，Ｆ２１５６，Ｆ３６２４，Ｆ５４９７，Ｆ７５３１は特定のトランザクションの一部として更新されているのではなく、どのトランザクションとも関連せずに更新されていることを示す。以下で説明するように、共有データ管理部４を介して更新中のファイルは、どのトランザクションとも関連しない状態で更新するので、このエントリに記録される。なお、このエントリに記録されるファイルがどのトランザクションによって更新されているかは、共有データ管理部４の更新管理表４１を参照すれば知ることができる。
【００４０】
以下は、データの一例としてＸＭＬドキュメントの形式での情報を例にとり、共有データ管理部４を介して、このＸＭＬドキュメントの形式で情報が記録されているファイルを更新するトランザクション処理システムに本発明を適応した場合についてより具体的に説明する。
【００４１】
なお、ＸＭＬに関しては、“Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ （ＸＭＬ） １．０”（Ｗ３Ｃ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ １０−Ｆｅｂ−９８）に開示されている。
【００４２】
この場合、トランザクション処理システムでは、「キー」とそれに対する「値」のペアの集合を、ＸＭＬのドキュメントの形式でファイルに記録して管理している。このドキュメントは、キーを指定してその値を検索するという、一般的なデータベースとして使用することができる。
【００４３】
図４に、そのようなドキュメントの一例を示す。
この例のＸＭＬドキュメントでは、＜ｋｅｙ＞と＜／ｋｅｙ＞のタグで囲まれた部分に「キー」を保持し、＜ｖａｌｕｅ＞と＜／ｖａｌｕｅ＞のタグで囲まれた部分に「値」を保持し、そのペアを＜ｅｎｔｒｙ＞と＜／ｅｎｔｒｙ＞のタグで囲んだエントリを作り、それらが複数集まったものを、最も外の＜ＫＶｔａｂｌｅ＞と＜／ＫＶｔａｂｌｅ＞のタグが囲んでいる。実際には、ＸＭＬドキュメントは先頭部分に＜？ｘｍｌ＞で始まるプロローグ部を持つが、ここでは省略する。なお、ＸＭＬの用語として、＜ｋｅｙ＞のような開始タグと、＜／ｋｅｙ＞のようなそれに対応する終了タグで囲まれた部分を、エレメントと呼ぶ。
【００４４】
図４に例示したＸＭＬドキュメントでは、キー「ＡＰＰＬＥ」に対応する値は「４００円」であり、キー「ＢＩＳＣＵＩＴ」に対応する値は「２５０円」であり、キー「ＣＨＯＣＯＬＡＴＥ」に対応する値は「２００円」であり、キー「ＧＲＡＰＥ」に対応する値は「６００円」になっている。
【００４５】
このＸＭＬドキュメントのファイルに対して、トランザクションを実行するアプリケーションプログラム２およびトランザクションマネージャ８は、共有データ管理部４を介して、ＲＥＡＤ（ｔｘｉｄ，ｋｅｙ）とＵＰＤＡＴＥ（ｔｘｉｄ，ｋｅｙ，ｖａｌｕｅ）とＲＥＭＯＶＥ（ｔｘｉｄ，ｋｅｙ）とＣＯＭＭＩＴ（ｔｘｉｄ）とＡＢＯＲＴ（ｔｘｉｄ）の５種類の操作ができるものとする。本実施形態では、ＲＥＡＤ、ＵＰＤＡＴＥ、ＲＥＭＯＶＥはアプリケーションプログラム２が指示し、ＣＯＭＭＩＴとＡＢＯＲＴはトランザクションマネージャ８が指示するものとする。なお、前述したように、トランザクションマネージャ８が存在せず、アプリケーションプログラム２がＣＯＭＭＩＴやＡＢＯＲＴも指示するように実施することもできる。
【００４６】
ＲＥＡＤ（ｔｘｉｄ，ｋｅｙ）は、ｔｘｉｄで指定したトランザクション識別子を持つトランザクションが、ｋｅｙで指定したエントリの値を読み出す操作である。
【００４７】
ＵＰＤＡＴＥ（ｔｘｉｄ，ｋｅｙ，ｖａｌｕｅ）は、ｔｘｉｄで指定したトランザクション識別子を持つトランザクションが、ｋｅｙで指定したエントリの値をｖａｌｕｅで指定した値に更新する操作である。ｋｅｙで指定したエントリが無い場合には、新しくエントリを作成する。
【００４８】
ＲＥＭＯＶＥ（ｔｘｉｄ，ｋｅｙ）は、ｔｘｉｄで指定したトランザクション識別子を持つトランザクションが、ｋｅｙで指定したエントリを削除する操作である。
【００４９】
ＣＯＭＭＩＴ（ｔｘｉｄ）は、ｔｘｉｄで指定したトランザクション識別子を持つトランザクションが行ったファイルの内容の変更を、ディスク上のファイルに書き戻して、変更を永久的なものにする。
【００５０】
ＡＢＯＲＴ（ｔｘｉｄ）は、ｔｘｉｄで指定したトランザクション識別子を持つトランザクションが行ったファイルの内容の変更を、すべて取り消して無かったものにする。
【００５１】
これらの５つの操作のうち、ＲＥＡＤはファイルの内容を変更しない操作であるのに対し、ＵＰＤＡＴＥとＲＥＭＯＶＥはファイルの内容を変更する操作である。ＣＯＭＭＩＴとＡＢＯＲＴは、トランザクションの処理結果をコミットすなわち正しく完了した状態にするか、アボートすなわち処理結果をキャンセルして処理開始前の状態にする操作である。
【００５２】
図４のＸＭＬドキュメントに対して、３つのトランザクション（ｔｘｉｄ＝１のトランザクション（１）、ｔｘｉｄ＝２のトランザクション（２）、ｔｘｉｄ＝３のトランザクション（３）とする）が、以下に示すように並行にアクセスする場合の動作を例に、本実施形態のトランザクション処理システムの動作を説明する。
［１］ ＵＰＤＡＴＥ（１，ＩＣＥＣＲＥＡＭ，４５０円）
［２］ ＵＰＤＡＴＥ（３，ＡＰＰＬＥ，５００円）
［３］ ＲＥＭＯＶＥ（２，ＢＩＳＣＵＩＴ）
［４］ ＵＰＤＡＴＥ（２，ＣＨＯＣＯＬＡＴＥ，３００円）
［５］ ＲＥＭＯＶＥ（１，ＧＲＡＰＥ）
［６］ ＵＰＤＡＴＥ（２，ＫＩＷＩＦＲＵＩＴ，３００円）
［７］ ＣＯＭＭＩＴ（３）
［８］ ＣＯＭＭＩＴ（１）
［９］ ＡＢＯＲＴ（２）
本トランザクション処理システムが図４のファイルを更新する場合、まず、共有データ管理部４から指示されたファイルシステム６が、ハードディスク１０にあるファイルの内容をバッファ領域６２に読み出す。トランザクションがコミットするまでは、ファイルの更新はバッファ領域６２にあるコピーに対してのみ行い、ハードディスク１０には書き戻さない。
【００５３】
［１］最初に、ＵＰＤＡＴＥ（１，ＩＣＥＣＲＥＡＭ，４５０円）で、トランザクション（１）がキー「ＩＣＥＣＲＥＡＭ」を追加してその値を「４５０円」にする。このとき、ファイルがまだバッファ領域６２に無ければ読み込む。その後、バッファ上のデータに対して、図５に示すようにバッファ領域６２のデータを変更する。ここでは、新しい「ＩＣＥＣＲＥＡＭ」をキーにするエントリを追加し、その値を「４５０円」にする。さらに、このエントリがトランザクション（１）によって更新中であることを示すために、＜ｅｎｔｒｙ＞タグの属性としてＴＸＩＤとＴＸＳＴＡＴＥの２つを記録しておく。属性ＴＸＩＤの値には変更を行ったトランザクションのトランザクション識別子を、属性ＴＸＳＴＡＴＥには変更の種類を記録しておき、ＣＯＭＭＩＴあるいはＡＢＯＲＴの処理時にこの情報を使用する。ここでは、ＴＸＩＤ属性の値としてトランザクション識別子「１」と、ＴＸＳＴＡＴＥ属性の値として更新中を示す「ＵＰＤＡＴＥ」を持たせる。
【００５４】
［２］続いて、ＵＰＤＡＴＥ（３，ＡＰＰＬＥ，５００円）で、トランザクション（３）がキー「ＡＰＰＬＥ」の値を「５００円」に変更する。このときは、バッファ領域６２のデータを図６に示すように変更する。ここでは、「ＡＰＰＬＥ」をキーにするエントリの＜ｖａｌｕｅ＞タグを＜ｏｌｄｖａｌｕｅ＞タグに変更して残しておき、新しい値「５００円」を＜ｖａｌｕｅ＞タグで囲ったエレメントを作成してエントリに追加する。さらに、エントリのには、ＴＸＩＤ属性の値としてトランザクション識別子「３」と、ＴＸＳＴＡＴＥ属性の値として更新中を示す「ＵＰＤＡＴＥ」を持たせる。
【００５５】
［３］次に、ＲＥＭＯＶＥ（２，ＢＩＳＣＵＩＴ）で、トランザクション（２）がキー「ＢＩＳＣＵＩＴ」のエントリを削除する。このときは、バッファ領域６２のデータを図７に示すように変更する。ここでは、「ＢＩＳＣＵＩＴ」をキーにするエントリの、ＴＸＩＤ属性の値にトランザクション識別子「２」を、ＴＸＳＴＡＴＥ属性の値に削除されたことを示す「ＲＥＭＯＶＥ」を持たせる。
【００５６】
［４］次に、ＵＰＤＡＴＥ（２，ＣＨＯＣＯＬＡＴＥ，３００円）でトランザクション（２）がキー「ＣＨＯＣＯＬＡＴＥ」の値を３００円に変更した後のバッファ領域６２のデータは、これまでと同様の処理を行って図８のようになる。
【００５７】
［５］次に、ＲＥＭＯＶＥ（１，ＧＲＡＰＥ）でトランザクション（１）がキー「ＧＲＡＰＥ」のエントリを削除した後のバッファ領域６２のデータは、これまでと同様の処理を行って図９のようになる。
【００５８】
［６］次に、ＵＰＤＡＴＥ（２，ＫＩＷＩＦＲＵＩＴ，３００円）でトランザクション（２）がキー「ＫＩＷＩＦＲＵＩＴ」に対応するエントリを追加してその値を「３００円」にした後のバッファ領域６２のデータは、これまでと同様の処理を行って図１０のようになる。
【００５９】
［７］続いて、ＣＯＭＭＩＴ（３）でトランザクション（３）のコミット処理が起動される。
【００６０】
このように複数のトランザクションが同じファイルを更新している場合のコミット処理の方式について説明する。
【００６１】
図１０のようにファイルのデータがバッファ領域６２上で変更されている状態で、ＣＯＭＭＩＴ（３）でトランザクション（３）のコミット処理が起動されたとする。このとき、図１１に示すように、トランザクション（３）による変更を、エレメントにＴＸＩＤやＴＸＳＴＡＴＥがついたり＜ｏｌｄｖａｌｕｅ＞タグを持っている一時的な状態から、それらを削除してハードディスク１０に書き戻しても良い正しく更新された状態に変更する。こうしてトランザクション（３）の変更を反映したファイルのデータができると、それを書き戻してハードディスク１０にある元のファイルを置き換える。このとき、本実施形態では、トランザクション（１）やトランザクション（２）による変更途中の状態のデータは、その変更途中のままハードディスク１０に書き戻すことができる（後述するように、変更途中の状態のデータにはその更新を取り消すのに必要な情報を付加しているので、次に読み出したときに更新を取り消すための処理を行うことができる）。
【００６２】
［８］次に、ＣＯＭＭＩＴ（１）でトランザクション（１）のコミット処理が起動されたとする。このとき、図１２に示すように、トランザクション（１）による変更を反映させ、それをハードディスク１０に書き戻す。
【００６３】
［９］次に、ＡＢＯＲＴ（２）でトランザクション（２）がアボートしたとする。このとき図１３に示すように、バッファ領域６２にあるファイルのデータからトランザクション（２）による変更を取り消す。
【００６４】
以下では、これまでの例で説明した各々の操作の処理手順を説明する。
【００６５】
まず、ＲＥＡＤの処理手順について説明する。
【００６６】
ＲＥＡＤの操作は指定されたキーに対応するエントリの値を読み出すだけなので簡単である。ただし、ＲＥＡＤの実装には、そのシステムの使い方に応じて２通りの場合がある。他のトランザクションが更新中でなければ値を読み出せるという点に関しては共通であるが、あるトランザクションが読み出したエントリを、そのトランザクションが終了する前に他のトランザクションが更新できるか否かで２通りの方式に分かれる。つまり、１つの方式は、更新できるという解釈で、ＲＥＡＤに関しては何の排他制御もしないという方式である。もう１つの方式は、更新できないと言う解釈で、広く知られたＲＥＡＤ／ＷＲＩＴＥロックのセマンティクスに従って排他制御する方式である。すなわち、同じトランザクションによるＲＥＡＤと更新は両立するが、異なるトランザクションによるＲＥＡＤと更新は両立せず、また、異なるトランザクションのＲＥＡＤどうしは両立するというものである。排他制御をする後者の方式は、排他制御をしない前者の方式を包含するので、ここでは後者の方式の場合の処理手順を説明する。排他制御しない前者の方式は、後者の方式においてＲＥＡＤについては何も制御しないのと等価である。
【００６７】
図１４にＲＥＡＤ（ｔｘｉｄ，ｋｅｙ）の処理手順の一例を示す。
【００６８】
まず、キーの値がｋｅｙに指定されたものと同じエントリを探す（ステップＳ１１）。
【００６９】
エントリが見つかったならば（ステップＳ１２）、そのエントリにＴＸＳＴＡＴＥ属性が付いているか否か、またＴＸＳＴＡＴＥ属性が付いているならばそのＴＸＳＴＡＴＥ属性が「ＲＥＡＤ」「ＵＰＤＡＴＥ」「ＲＥＭＯＶＥ」のいずれであるかを調べる（ステップＳ１３）。
【００７０】
ＴＸＳＴＡＴＥ属性が付いていない場合は、誰もアクセスしていないので、そのエントリにＴＸＩＤ属性とＴＸＳＴＡＴＥ属性を付け、ＴＸＩＤ属性の値は「ｔｘｉｄ」に、ＴＸＳＴＡＴＥ属性の値は「ＲＥＡＤ」にし（ステップＳ１４）、＜ｖａｌｕｅ＞部の値を結果として返す（ステップＳ１５）。
【００７１】
ＴＸＳＴＡＴＥ属性の値が「ＲＥＡＤ」の場合は、そのＴＸＩＤ属性にまだ「ｔｘｉｄ」が入っていなければ追加し（ステップＳ１６，Ｓ１７）、＜ｖａｌｕｅ＞部の値を結果として返す（ステップＳ１８）。
【００７２】
ＴＸＳＴＡＴＥ属性の値が「ＵＰＤＡＴＥ」の場合は、同じトランザクションが変更した値であれば読めるので（ステップＳ１９）、＜ｖａｌｕｅ＞部の値を結果として返す（ステップＳ２０）。そうでない場合には、他のトランザクションが使用中で読めないことを知らせる。
【００７３】
ＴＸＳＴＡＴＥ属性の値が「ＲＥＭＯＶＥ」ならば（ステップＳ１３）、無いものを読もうとしているのでエラーになる。
【００７４】
なお、エントリが見つからなかったならば（ステップＳ１２）、エラーとなる。
【００７５】
図１５に、図４の状態のファイルのデータに対して、ＲＥＡＤ（４，ＣＨＯＣＯＬＡＴＥ）でトランザクション４がキー「ＣＨＯＣＯＬＡＴＥ」の値を読み出した直後のバッファ領域６２上のデータの状態を示す。
【００７６】
通常、ＴＸＩＤの値はトランザクション識別子を１つ持っているが、ＴＸＳＴＡＴＥ属性の値が「ＲＥＡＤ」の場合のＴＸＩＤ属性にはトランザクション識別子のリストを持つことが出来る。これは、複数のトランザクションが同時に読み出すことが出来るためである。例えば、トランザクション識別子が１と４と５のトランザクションがＲＥＡＤしている場合、そのＴＸＩＤ属性の値は「１ ４ ５」のようなリストになっている。
【００７７】
次に、ＵＰＤＡＴＥの処理手順について説明する。
【００７８】
図１６に、ＵＰＤＡＴＥ（ｔｘｉｄ，ｋｅｙ，ｖａｌｕｅ）の処理手順の一例を示す。
【００７９】
まず、キーの値がｋｅｙに指定されたものと同じエントリを探す（ステップＳ２１）。
【００８０】
エントリが見つかったならば（ステップＳ２２）、そのエントリにＴＸＳＴＡＴＥ属性が付いているか否か、またＴＸＳＴＡＴＥ属性が付いているならばそのＴＸＳＴＡＴＥ属性が「ＲＥＡＤ」「ＵＰＤＡＴＥ」「ＲＥＭＯＶＥ」のいずれであるかを調べる（ステップＳ２３）。
【００８１】
ＴＸＳＴＡＴＥ属性が付いていない場合は、誰もアクセスしていないので、そのエントリにＴＸＩＤ属性とＴＸＳＴＡＴＥ属性を付け、ＴＸＩＤ属性の値は「ｔｘｉｄ」に、ＴＸＳＴＡＴＥ属性の値は「ＵＰＤＡＴＥ」にし、現在の＜ｖａｌｕｅ＞部のタグ名を＜ｏｌｄｖａｌｕｅ＞に変更して退避し、新しく＜ｖａｌｕｅ＞部を作ってその値をＵＰＤＡＴＥの第３引数のｖａｌｕｅに指定されたものにする（ステップＳ２４）。
【００８２】
ＴＸＳＴＡＴＥ属性の値が「ＲＥＡＤ」の場合は、同じトランザクションだけがＲＥＡＤしている場合に限って更新できる。この場合は（ステップＳ２５）、ＴＸＳＴＡＴＥ属性の値を「ＵＰＤＡＴＥ」に変更し、現在の＜ｖａｌｕｅ＞部のタグ名を＜ｏｌｄｖａｌｕｅ＞に変更して退避し、新しく＜ｖａｌｕｅ＞部を作ってその値をＵＰＤＡＴＥの第３引数のｖａｌｕｅに指定されたものにする（ステップＳ２６）。他のトランザクションがＲＥＡＤ中であれば、ＵＰＤＡＴＥすることができないので、使用中であることを知らせる。
【００８３】
ＴＸＳＴＡＴＥ属性の値が「ＵＰＤＡＴＥ」の場合は、同じトランザクションが更新したエントリであれば（ステップＳ２７）、その＜ｖａｌｕｅ＞部の値をＵＰＤＡＴＥの第３引数のｖａｌｕｅに指定されたものに変更する（ステップＳ２８）。他のトランザクションがＵＰＤＡＴＥ中であればＵＰＤＡＴＥすることができないので、使用中であることを知らせる。
【００８４】
ＴＸＳＴＡＴＥ属性の値が「ＲＥＭＯＶＥ」の場合は（ステップＳ２３）、無いものを更新しようとしているのでエラーになる。
【００８５】
なお、キーの値がｋｅｙに指定されたものと同じエントリが見つからない場合は（ステップＳ２２）、新しくエントリを作成し、＜ｋｅｙ＞部の値と＜ｖａｌｕｅ＞部の値を、それぞれＵＰＤＡＴＥの第２引数と第３引数に指定されたものにしたエントリを作成し、そのＴＸＩＤ属性の値を「ｔｘｉｄ」に、ＴＸＳＴＡＴＥ属性の値を「ＵＰＤＡＴＥ」にする（ステップＳ２９）。
【００８６】
次に、ＲＥＭＯＶＥの処理手順について説明する。
【００８７】
図１７に、ＲＥＭＯＶＥ（ｔｘｉｄ，ｋｅｙ）の処理手順の一例を示す。
【００８８】
まず、キーの値がｋｅｙに指定されたものと同じエントリを探す（ステップＳ３１）。
【００８９】
エントリが見つかったならば（ステップＳ３２）、そのエントリにＴＸＳＴＡＴＥ属性が付いているか否か、またＴＸＳＴＡＴＥ属性が付いているならばそのＴＸＳＴＡＴＥ属性が「ＲＥＡＤ」「ＵＰＤＡＴＥ」「ＲＥＭＯＶＥ」のいずれであるかを調べる（ステップＳ３３）。
【００９０】
ＴＸＳＴＡＴＥ属性が付いていない場合は、誰もアクセスしていないので、ＴＸＩＤ属性の値を「ｔｘｉｄ」に、ＴＸＳＴＡＴＥ属性の値を「ＲＥＭＯＶＥ」にする（ステップＳ３４）。
【００９１】
ＴＸＳＴＡＴＥ属性の値が「ＲＥＡＤ」の場合には、同じトランザクションだけがＲＥＡＤしている場合に限ってＲＥＭＯＶＥできる。この場合は（ステップＳ３５）、ＴＸＳＴＡＴＥ属性の値を「ＲＥＭＯＶＥ」に変更する（ステップＳ３６）。他のトランザクションがＲＥＡＤ中であればＲＥＭＯＶＥすることができないので、使用中であることを知らせる。
【００９２】
ＴＸＳＴＡＴＥ属性の値が「ＵＰＤＡＴＥ」の場合は、同じトランザクションが更新したエントリであれば（ステップＳ３７）、ＲＥＭＯＶＥできる。このとき、＜ｏｌｄｖａｌｕｅ＞部があるかどうかで、そのエントリがこのトランザクションで新しく作られたものか、以前から存在していたものかがわかる。＜ｏｌｄｖａｌｕｅ＞部が無い場合には（ステップＳ３８）、このトランザクションが作成したエントリなので、即座にエントリを削除してしまって良い（ステップＳ４０）。そうでない場合には（ステップＳ３８）、ＴＸＳＴＡＴＥ属性の値を「ＲＥＭＯＶＥ」に変更する（ステップＳ３９）。他のトランザクションがＵＰＤＡＴＥ中であれば（ステップＳ３７）、ＲＥＭＯＶＥすることができないので、使用中であることを知らせる。
【００９３】
ＴＸＳＴＡＴＥ属性の値が「ＲＥＭＯＶＥ」の場合は（ステップＳ３３）、無いものを削除しようとしているのでエラーになる。
【００９４】
なお、エントリが見つからなかったならば（ステップＳ３２）、エラーとなる。
【００９５】
次に、ＣＯＭＭＩＴの処理手順について説明する。
【００９６】
図１８に、ＣＯＭＭＩＴ（ｔｘｉｄ）の処理手順の一例を示す。
【００９７】
ＣＯＭＭＩＴの処理時には、ファイル中のすべてのエントリに対して図１８の手順で処理を行う。
【００９８】
まず、そのエントリのＴＸＳＴＡＴＥ属性の値を調べる（ステップＳ１０１）。
【００９９】
ＴＸＳＴＡＴＥ属性を持たない場合は、どのトランザクションもアクセスしていないので何もしなくて良い。
【０１００】
ＴＸＳＴＡＴＥ属性が「ＲＥＡＤ」の場合は、そのＴＸＩＤ属性の中にｔｘｉｄが含まれていて（ステップＳ１０２）、ｔｘｉｄ以外のトランザクション識別子も含まれていれば（ステップＳ１０３）、ｔｘｉｄを抜く（ステップＳ１０４）。ＴＸＩＤ属性がｔｘｉｄのみをもっている場合には（ステップＳ１０３）、ＴＸＩＤ属性とＴＸＳＴＡＴＥ属性を削除する（ステップＳ１０５）。
【０１０１】
次に、ＴＸＳＴＡＴＥ属性の値が「ＵＰＤＡＴＥ」の場合は、そのＴＸＩＤ属性の値がｔｘｉｄと同じであれば（ステップＳ１０６）、＜ｏｌｄｖａｌｕｅ＞部とＴＸＩＤ属性とＴＸＳＴＡＴＥ属性を削除してその更新を有効にする（ステップＳ１０７）。
【０１０２】
ＴＸＳＴＡＴＥ属性がＲＥＭＯＶＥの場合は（ステップＳ１０１）、そのＴＸＩＤ属性の値がｔｘｉｄと同じであれば（ステップＳ１０８）、そのエントリを削除する（ステップＳ１０９）。
【０１０３】
すべてのエントリに関して以上の処理が終了すれば、その時点のバッファ領域６２上のデータをハードディスク１０上に書き戻して、ファイルを更新する。
【０１０４】
ところで、ＣＯＭＭＩＴ処理の最後に、共有データ管理部４は、バッファ領域６２上で更新したファイルをハードディスク１０に書き込むように、ファイルシステム６に指示する。このとき、このファイルの書き込みは、コミットするトランザクションが更新した他のファイルと同期してアトミックに書き込む必要がある。すなわち、トランザクションを実行するアプリケーションプログラム２は、共有データ管理部４を介さずにファイルシステム６に直接指示して複数のファイルの更新を行っている可能性があり、また、共有データ管理部４を介しても複数のファイルを更新している可能性がある（図２および図３参照）。トランザクションとしてアトミックにコミットするためには、これらの複数のファイルへの更新がすべて完全に行われるなければならない。本実施形態のトランザクション処理システムでは、ファイルシステム６は、トランザクション管理表６１によって、アプリケーションプログラム２から直接指示されて更新したファイルのリストをトランザクション毎に管理しており、その情報を用いて、同じトランザクションが更新したファイルを一括してアトミックにハードディスク１０に書き戻すことができる。
【０１０５】
しかし、共有データ管理部４を介して操作しているファイルに関しては、ファイルシステム６内ではどのトランザクションとも関連しないファイルとして管理されている。それらのファイルをどのトランザクションのコミット時に書き戻せば良いかは、共有データ管理部４がＣＯＭＭＩＴの処理時に判断する。
【０１０６】
そこで、共有データ管理部４がどのトランザクションとも関連せずにオープンして更新したファイルに対して、特定のトランザクションのコミット時に同期してアトミックにハードディスク１０に書き戻すことを指示する機能を、ファイルシステム６に持たせる。ＣＯＭＭＩＴの処理を行う共有データ管理部４は、指定されたトランザクション識別子のトランザクションによる更新をファイルに反映させた後、そのファイルを指定されたトランザクション識別子のトランザクションと同期してハードディスク１０に書き戻すように、ファイルシステム６に指示する。ファイルシステム６は、このようにして指定されたファイルを、指定されたトランザクション識別子のトランザクションのコミット時に、トランザクション管理表６１にあるそのトランザクションが更新したファイルと同時に、アトミックにハードディスク１０に書き戻す。
【０１０７】
ただし、ファイルシステム６のコミット処理が終了後は、トランザクションを実行するアプリケーションプログラム２が直接ファイルシステム６に指示して更新したファイルの情報（トランザクション管理表６１のエントリやバッファ領域６２にあるファイルのイメージ）は不要になる。一方、共有データ管理部４が特定のトランザクションに関連せずに更新しているファイルは、その後も他のトランザクションによって更新が続けられるため、どのトランザクションとも関連しない状態のまま共有データ管理部４によって使い続けられる。そのため、ファイルシステム６はそれらのファイルに関する情報は維持しつづける。
【０１０８】
次に、ＡＢＯＲＴの処理手順について説明する。
【０１０９】
図１９に、ＡＢＯＲＴ（ｔｘｉｄ）の処理手順の一例を示す。
【０１１０】
ＡＢＯＲＴの処理時には、すべてのエントリに対して図１９の手順で処理を行う。
【０１１１】
まず、そのエントリのＴＸＳＴＡＴＥ属性の値を調べる（ステップＳ１１１）。
【０１１２】
ＴＸＳＴＡＴＥ属性を持たない場合は、どのトランザクションもアクセスしていないので何もしなくて良い。
【０１１３】
ＴＸＳＴＡＴＥ属性が「ＲＥＡＤ」の場合は、そのＴＸＩＤ属性の中にｔｘｉｄが含まれていて（ステップＳ１１２）、ｔｘｉｄ以外のトランザクション識別子も含まれていれば（ステップＳ１１３）、ｔｘｉｄを抜く（ステップＳ１０４）。ＴＸＩＤ属性がｔｘｉｄのみをもっている場合には（ステップＳ１１３）、ＴＸＩＤ属性とＴＸＳＴＡＴＥ属性を削除する（ステップＳ１１５）。
【０１１４】
ＴＸＳＴＡＴＥ属性の値が「ＵＰＤＡＴＥ」の場合は、そのＴＸＩＤ属性の値がｔｘｉｄと同じであれば（ステップＳ１１６）、そのエントリのＵＰＤＡＴＥを取り消す操作を行う。このとき、そのエントリに＜ｏｌｄｖａｌｕｅ＞部があれば（ステップＳ１１７）、現在の＜ｖａｌｕｅ＞部を削除して＜ｏｌｄｖａｌｕｅ＞部のタグ名を＜ｖａｌｕｅ＞に戻すことで更新前の値に戻すとともに、ＴＸＩＤ属性とＴＸＳＴＡＴＥ属性を削除する（ステップＳ１１８）。そのエントリに＜ｏｌｄｖａｌｕｅ＞部が無い場合は（ステップＳ１１７）、このトランザクションで新しく作成したエントリであるので、エントリを削除する（ステップＳ１１９）。
【０１１５】
ＴＸＳＴＡＴＥ属性がＲＥＭＯＶＥの場合は（ステップＳ１１１）、そのＴＸＩＤ属性の値がｔｘｉｄと同じであれば（ステップＳ１２０）、ＴＸＩＤ属性とＴＸＳＴＡＴＥ属性を削除して、ＲＥＭＯＶＥを取り消す（ステップＳ１２１）。
【０１１６】
ところで、ＡＢＯＲＴの場合、アボートするトランザクションによるファイルの更新を、バッファ領域６２上で取り消す。このとき、同じファイルを更新していて既にコミットした他のトランザクションがあった場合には、アボートするトランザクションによる更新中の状態もファイルに書きこまれてしまっている可能性がある。しかし、ＡＢＯＲＴ処理時にバッファ領域６２上で取り消した結果のファイルをハードディスク１０に書き込むことは、必ずしも必要無い。なぜなら、次に同じファイルを他のトランザクションが更新してコミットすれば、アボートしたトランザクションによる更新の取り消しはハードディスク１０上に正しく反映される。また、たとえ次にどのトランザクションも更新せずに、そのまま計算機の障害等で忘れ去られてしまった場合でも、後で述べるリカバリ処理によって、次にそのファイルをオープンする時に、ハードディスク１０上のファイルに残っているコミットしていないトランザクションによる更新途中の状態は取り消される。
【０１１７】
次に、リカバリの処理手順について説明する。
【０１１８】
本実施形態のトランザクション処理システムでは、コミットしていないトランザクションによって更新途中のファイルの状態がハードディスク１０に書き戻される。そのため、障害で計算機がダウンした場合には、更新途中の状態が残るので、リカバリ処理を行って更新途中で残された変更を取り消さなくてはいけない。従来のトランザクション処理方式では、このようなリカバリ処理は障害が起こって再起動した直後にまとめて行わなければならない。そのため、障害直後の再起動のオーバヘッドは大きい。しかし、本実施形態のトランザクション処理方式では、リカバリ処理は、次にそのファイルをハードディスク１０から読み出す時点で良い。
【０１１９】
図２０に、リカバリの処理手順の一例を示す。
【０１２０】
共有データ管理部４がまだバッファ領域６２にないファイルを参照するためにオープン処理をファイルシステム６に指示すると、ファイルシステム６はそのファイルをハードディスク１０から読み出してバッファ領域６２にコピーする。その時点で共有データ管理部４は、すべてのエントリに対して図２０に示す手順でリカバリ処理を実行する。
【０１２１】
まず、そのエントリのＴＸＳＴＡＴＥ属性を調べる（ステップＳ２０１）。
【０１２２】
ＴＸＳＴＡＴＥ属性を持たない場合は、どのトランザクションもアクセスしていないので何もしなくて良い。
【０１２３】
ＴＸＳＴＡＴＥ属性の値が「ＲＥＡＤ」の場合は、ＴＸＩＤ属性とＴＸＳＴＡＴＥ属性を削除するだけで良い（ステップＳ２０２）。
【０１２４】
ＴＸＳＴＡＴＥ属性の値が「ＵＰＤＡＴＥ」の場合は、いずれかのトランザクションが更新している途中で障害が発生したことを示しているので、それらをアボートする。このときの動作は、そのエントリに＜ｏｌｄｖａｌｕｅ＞部があるかどうかで異なる。＜ｏｌｄｖａｌｕｅ＞部があれば（ステップＳ２０３）、そのトランザクションの開始以前から存在していたエントリであるので、まず現在の＜ｖａｌｕｅ＞部を削除し、＜ｏｌｄｖａｌｕｅ＞部のタグ名を＜ｖａｌｕｅ＞に変更して値を元に戻し、さらにＴＸＩＤ属性とＴＸＳＴＡＴＥ属性を削除する（ステップＳ２０４）。＜ｏｌｄｖａｌｕｅ＞部が無い場合は（ステップＳ２０３）、このトランザクションが作成したエントリであるので、エントリ全体を削除する（ステップＳ２０５）。
【０１２５】
ＴＸＳＴＡＴＥ属性の値が「ＲＥＭＯＶＥ」の場合は（ステップＳ２０１）、ＴＸＩＤ属性とＴＸＳＴＡＴＥ属性を削除するだけでＲＥＭＯＶＥをキャンセルすることが出来る（ステップＳ２０６）。
【０１２６】
ところで、ファイルをディスクから読み出す度にこのようなリカバリ処理を行うのでは、非常にオーバーヘッドが大きい。そこで、ファイルを書き出すときにそのファイルが更新途中の状態を含んでいるかどうかを簡単に識別できる情報を付けておくことで、このオーバヘッドを無くすことが出来る。その方式は、例えば図２１に示すように、ドキュメントのルートのエレメントの属性として、現在いくつのトランザクションがファイルを更新中かを示す情報を持たせる。図２１の例では、ルートである＜ＫＶｔａｂｌｅ＞のＴＸＮＵＭという属性がそれを示しており、現在、トランザクション（１）とトランザクション（２）の２つのトランザクションが更新中であることを示している。こうしておくと、最初にファイルをディスクから読みだして来た時に、そのルートエレメントがＴＸＮＵＭという属性を持っていたら、そのファイル内のすべてのエントリに対して図２０のリカバリ処理を実行する。もしＴＸＮＵＭという属性が無ければ、リカバリ処理は必要無い。
【０１２７】
さて、これまでの説明では、エントリはルートエレントである＜ＫＶｔａｂｌｅ＞の下にフラットに記録していたが、例えば良く知られた二分木のような構造を使って、検索を高速化するように実施することができる。図２２は、そのように実施した場合のファイルのデータの例である。この例では、エントリには＜ｋｅｙ＞と＜ｖａｌｕｅ＞以外に、＜ｌｅｓｓ＞と＜ｇｒｅａｔｅｒ＞というエレメントを持つ。そのエレメントのキーより小さなキーを持つエントリは＜ｌｅｓｓ＞の下に、大きなキーを持つエントリは＜ｇｒｅａｔｅｒ＞の下にくるように、二分木を構成している。この場合も、トランザクションによるＵＰＤＡＴＥやＲＥＭＯＶＥなどの更新はフラットな場合と同様に扱うことが出来る。ただし、エントリの追加や削除によって木の構成を組み換える処理が必要になる。この処理は通常の木構造のノードの追加／削除とまったく同じ処理である。木構造の組み換え時には、ＡＶＬ木のような手法を使ってうまく木がバランスするように組み換えたり、アクセス頻度の多いエントリが木のルートに近い場所に来るように組み換えたりするように実施することもできる。
【０１２８】
また、本発明は、良く知られたＢ−ＴＲＥＥのような管理構造を使って、ファイルを分割して管理するように実施することも出来る。図２３／図２４／図２５／図２６にその例を示す。ここでは、一つのファイルには最大６個のエントリを収容し、それ以上にエントリが増えるとファイルを分割するというような、Ｂ−ＴＲＥＥと同じアルゴリズムでエントリの追加／削除の処理を行うものとする。図２３／図２４／図２５／図２６の例では、ＦＩＬＥ００１がルートになるファイル、ＦＩＬＥ００２，ＦＩＬＥ００３，ＦＩＬＥ００４がその下にあるファイルである。
【０１２９】
図２７に、このように一纏まりの情報を複数のファイルに分割して記録・管理するようにしたトランザクション処理システムの構成例を示す。
【０１３０】
図２７の構成は、図１の構成と比べて、共有データ管理部４が更新グループ表４２を持つ点が異なる。後に説明するように、複数のファイル間で情報を移動してファイル間の構造を変更した場合に、それらのファイルをコミット時に同時にハードディスク１０に書き戻さなければならない。更新グループ表４２は、そのようなコミット時に同時にハードディスク１０に書き戻したりあるいは削除したりする必要のあるファイルのグループを管理するための表である。
【０１３１】
図２８に更新グループ表４２の例を示す。この更新グループ表には、コミット時に同時に書き戻したり削除したりすべきファイルのグループ毎に、そのメンバが記録されている。図２８では、例えば、ＦＩＬＥ００１とＦＩＬＥ００２とＦＩＬＥ００５がグループになっている。
【０１３２】
さて、図２３／図２４／図２５／図２６のＦＩＬＥ００１から始めて「ＳＥＳＡＭＥ」をキーとするエントリを探す手順は、ＦＩＬＥ００１のルートから始める。まずキーを「ＫＩＷＩＦＲＵＩＴ」と比べるとそれよりも大きい。次にキーを＜ｇｒｅａｔｅｒ＞側の「ＲＯＳＥＭＡＲＹ」と比べるとそれよりも大きい。次に＜ｇｒｅａｔｅｒ＞側を見るとＦＩＬＥ００４へのリンクになっている。そこでＦＩＬＥ００４に移って、キーを「ＴＨＹＭＥ」と比べるとそれよりも小さい。そこで＜ｌｅｓｓ＞側を見ると、キーが「ＳＥＳＡＭＥ」のエントリが見つかる。こうしてエントリが見つかれば、あとはそれへの操作はこれまでの実施形態と同様に、ＴＸＩＤ属性とＴＸＳＴＡＴＥ属性をつけて更新の途中状態を回復可能な形式で保存して行く。
【０１３３】
例えば、図２３／図２４／図２５／図２６の状態のデータに対して、トランザクション（１）がキー「ＯＲＡＮＧＥ」のエントリの値を「２５０円」に更新し、さらにキー「ＳＥＳＡＭＥ」のエントリの値を「１５０円」に更新し、それと並行に動いているトランザクション（２）がキー「ＶＯＤＫＡ」のエントリを削除したとする。この状態で図２３／図２４／図２５／図２６のデータは図２９／図３０のような状態になる。ＵＰＤＡＴＥやＲＥＭＯＶＥなどの更新途中の状態の持ち方は、一つのファイルにすべてのエントリを入れる場合と同じであり、更新したエントリにはＴＸＩＤとＴＸＳＴＡＴＥの２つの属性をつけて管理する。
【０１３４】
図２９／図３０の状態で、トランザクション（１）と（２）が順にコミットおよびアボートする場合の動作例を説明する。
【０１３５】
まず、トランザクション（１）のコミット時には、トランザクション（１）によって更新されたエントリはファイルＦＩＬＥ００３とＦＩＬＥ００４にのみ存在している。そこで、ＦＩＬＥ００３とＦＩＬＥ００４に対してコミット処理を行った図３１／図３２の状態のデータを作成し、これをトランザクション（１）による他のファイルの更新と同時にハードディスク１０に書き戻す。このとき、ＦＩＬＥ００４にはトランザクション（２）による更新途中の状態が含まれたまま書き戻すのは、これまでの実施形態と同じである。
【０１３６】
次に、トランザクション（２）のアボート時には、トランザクション（２）によって更新されたエントリはＦＩＬＥ００４にのみ存在している。そこでＦＩＬＥ００４に対してアボート処理を行った図３３の状態を作成して、アボート処理は終了する。アボート処理時にはファイルのハードディスク１０への書き戻しは必要無いのは、これまでの実施形態と同じである。
【０１３７】
さて、この状態で、新しくトランザクション（３）がキー「ＤＯＤＯ」とキー「ＨＯＯＰＯＥ」のエントリを追加し、それぞれの値を「５００００００円」と「９８００００円」にした後のデータの状態を、図３４／図３５／図３６に示す。ここでは、一つのファイルに入れることの出来るエントリの数は決まっているので、この更新例のように一つのファイルにその容量以上のエントリを追加しようとした場合には、ファイル間で組み換えが発生してエントリが移動する。図３４／図３５／図３６の例では、キー「ＤＯＤＯ」とキー「ＨＯＯＰＯＥ」の二つのエントリを追加しようとしたところ、それらはどちらもＦＩＬＥ００２への追加となる。その結果ＦＩＬＥ００２の分割が行われて、新たにＦＩＬＥ００５が作られてエントリが移動している。
【０１３８】
このようにファイル間でエントリ情報の移動が発生したり、新しいファイルが追加されたり、あるいは逆にファイルが削除されたりすると、それらのファイルの更新は同時にハードディスク１０へ反映させなければならない。そのために、本実施形態のトランザクション処理システムの共有データ管理部４は、更新グループ表４２を管理している。図３４／図３５／図３６の例のように、ＦＩＬＥ００２へのエントリの追加によってＦＩＬＥ００２の分割が発生し、ＦＩＬＥ００１の更新とＦＩＬＥ００５の作成が発生した場合、共有データ管理部４は更新グループ表４２にＦＩＬＥ００１とＦＩＬＥ００２とＦＩＬＥ００５をひとつのグループとして登録する。
【０１３９】
トランザクション（３）のコミットを行う場合、トランザクション（３）が更新したエントリはＦＩＬＥ００１とＦＩＬＥ００５のみに存在するが、更新グループ表４２を参照することで、ＦＩＬＥ００２も同時に書き戻さなければならないことがわかる。そこで、図３７／図３８に示すようにコミット処理を行ったＦＩＬＥ００１とＦＩＬＥ００５に加えてＦＩＬＥ００２の３つのファイルをハードディスク１０に書き戻す。
【０１４０】
このように複数のファイルに分割してデータを持つように本発明を実施する場合には、様々な基準で一つのファイルに入れられるエントリの数を制限することが出来る。そのような基準としては、図３４／図３５／図３６の例のように一つのファイル内のエントリの数で制限する方式、ファイルの物理的なサイズで制限する方式、追加削除の頻度等の情報によって最大のエントリ数を変更する方式、それらの組み合わせなど、様々な方式が考えられる。
【０１４１】
本実施形態のように複数のファイルに分割してデータを記憶する方式は、エントリの数が大きくなったときでも、その一部分しか更新していないなら、コミット時にディスクに書き出すデータ量を減らせるという効果がある。すべてのエントリを一つのファイルに入れる方式では、大きなファイルの一部しか変更していない場合でも、コミット時にファイル全体をディスクに書き戻す必要がある。
【０１４２】
さて、これまでは、キーと値とのペアというデータベース的な構造を持つデータに対して本発明を適用する場合を例とって説明してきた。以下では、他の例として、より一般的なＸＭＬドキュメントに対して本発明を適用する場合について説明する。
【０１４３】
図３９は、一般的なＸＭＬのドキュメントの例である。このドキュメントに対して、トランザクション（１）が「＜ｔｉｔｌｅ＞名古屋＜／ｔｉｔｌｅ＞」の＜ｃｈａｐｔｅｒ＞の＜ａｕｔｈｏｒ＞を「味噌かつ」に変更し、トランザクション（２）が「＜ｃｈａｐｔｅｒ＞＜ｔｉｔｌｅ＞博多＜／ｔｉｔｌｅ＞＜ａｕｔｈｏｒ＞からし明太子＜／ａｕｔｈｏｒ＞＜／ｃｈａｐｔｅｒ＞」を追加した状態のデータが図４０である。
【０１４４】
この後、トランザクション（１）のコミット時にデータを図４１の状態に更新し、これをディスクに書き戻す。
【０１４５】
さらに、トランザクション（２）のコミット時にはデータを図４２の状態に更新し、これをディスクに書き戻す。
【０１４６】
この一般的なＸＭＬドキュメントを対象にした実施形態でも、障害発生によって更新途中で残されたファイルは、次にディスクから読み出した時にチェックし、ＴＸＳＴＡＴＥがＡＤＤのエレメントは削除してＴＸＳＴＡＴＥがＲＥＭＯＶＥのエレメントは残すようなリカバリ処理を行うことで、コミットしていないトランザクションによる一時的な更新を取り消すことが出来る。
【０１４７】
本実施形態によれば、並行に動作する複数のトランザクションによるファイルの更新を、簡単な処理手順で実現することができる。本実施形態によれば、従来のＷＡＬ方式や、シャドウページ方式の上に特殊なログ管理を実装するときのように、データの更新時やコミット処理時あるいはリカバリ時に複雑な処理を必要としない。
【０１４８】
また、本実施形態では、障害発生後のリカバリ処理を、再起動時に集中して行う必要は無く、障害で更新途中の状態は次にそのファイルを使う時点で行われるため、リカバリ処理のオーバヘッドが小さい。
【０１４９】
さらに、本実施形態では、１つのデータを複数のファイルに分けて管理することで、ファイルの更新のコミット時にディスクに書き戻すデータの量を減らすことができる。
【０１５０】
なお、以上の各機能は、ソフトウェアとしても実現可能である。
【０１５１】
また、本実施形態は、コンピュータに所定の手段を実行させるための（あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるための）プログラムを記録したコンピュータ読取り可能な記録媒体としても実施することもできる。
【０１５２】
本発明は、上述した実施の形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。
【０１５３】
【発明の効果】
本発明によれば、並行に動作する複数のトランザクションによるファイルの更新処理と障害時のリカバリ処理を簡単に効率良く実現することができる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るトランザクション処理システムの構成例を示す図
【図２】更新管理表の一例を示す図
【図３】トランザクション管理表の一例を示す図
【図４】ＸＭＬドキュメント（データファイル）の一例を示す図
【図５】ＵＰＤＡＴＥ（１，ＩＣＥＣＲＥＡＭ，４５０円）の処理直後のデータの一例を示す図
【図６】ＵＰＤＡＴＥ（３，ＡＰＰＬＥ，５００円）の処理直後のデータの一例を示す図
【図７】ＲＥＭＯＶＥ（２，ＢＩＳＣＵＩＴ）の処理直後のデータの一例を示す図
【図８】ＵＰＤＡＴＥ（２，ＣＨＯＣＯＬＡＴＥ，３００円）の処理直後のデータの一例を示す図
【図９】ＲＥＭＯＶＥ（１，ＧＲＡＰＥ）の処理直後のデータの一例を示す図
【図１０】ＵＰＤＡＴＥ（２，ＫＩＷＩＦＲＵＩＴ，３００円）の処理直後のデータの一例を示す図
【図１１】ＣＯＭＭＩＴ（３）の処理直後のデータの一例を示す図
【図１２】ＣＯＭＭＩＴ（１）の処理直後のデータの一例を示す図
【図１３】ＡＢＯＲＴ（２）の処理直後のデータの一例を示す図
【図１４】ＲＥＡＤ（ｔｘｉｄ，ｋｅｙ）の処理手順の一例を示すフローチャート
【図１５】ＲＥＡＤ（４，ＣＨＯＣＯＬＡＴＥ）の処理直後のデータの一例を示す図
【図１６】ＵＰＤＡＴＥ（ｔｘｉｄ，ｋｅｙ，ｖａｌｕｅ）の処理手順の一例を示すフローチャート
【図１７】ＲＥＭＯＶＥ（ｔｘｉｄ，ｋｅｙ）の処理手順の一例を示すフローチャート
【図１８】ＣＯＭＭＩＴ（ｔｘｉｄ）の処理手順の一例を示すフローチャート
【図１９】ＡＢＯＲＴ（ｔｘｉｄ）の処理手順の一例を示すフローチャート
【図２０】リカバリの処理手順の一例を示すフローチャート
【図２１】トランザクションによる更新中情報を持つデータの一例を示す図
【図２２】二分木構造により検索を高速化するデータの一例を示す図
【図２３】複数ファイルに分割したデータ管理方式の一例を示す図
【図２４】複数ファイルに分割したデータ管理方式の一例を示す図
【図２５】複数ファイルに分割したデータ管理方式の一例を示す図
【図２６】複数ファイルに分割したデータ管理方式の一例を示す図
【図２７】本発明の一実施形態に係るトランザクション処理システムの他の構成例を示す図
【図２８】更新グループ表の一例を示す図
【図２９】トランザクション（１）と（２）による更新の例を示す図
【図３０】トランザクション（１）と（２）による更新の例を示す図
【図３１】トランザクション（１）のコミット処理の例を示す図
【図３２】トランザクション（１）のコミット処理の例を示す図
【図３３】トランザクション（２）のアボート処理の例を示す図
【図３４】トランザクション（３）による更新の例を示す図
【図３５】トランザクション（３）による更新の例を示す図
【図３６】トランザクション（３）による更新の例を示す図
【図３７】トランザクション（３）のコミット処理の例を示す図
【図３８】トランザクション（３）のコミット処理の例を示す図
【図３９】一般的なＸＭＬドキュメントの例を示す図
【図４０】トランザクション（１）と（２）によるデータの更新例を示す図
【図４１】トランザクション（１）コミット後のデータの一例を示す図
【図４２】トランザクション（２）コミット後のデータの一例を示す図
【図４３】従来のトランザクション処理システムの例を示す図
【符号の説明】
２…アプリケーションプログラム
４…共有データ管理部
４１…更新管理表
４２…更新グループ表
６…ファイルシステム
６１…トランザクション管理表
６２…バッファ領域
８…トランザクションマネージャ
１０…ハードディスク
【発明の属する技術分野】
本発明は、複数のトランザクションが並行して同じファイルにアクセスするトランザクション処理方法及びトランザクション処理システムに関する。
【０００２】
【従来の技術】
一般に、トランザクション処理システムにおいては、トランザクションと呼ぶ処理の流れを単位として処理の実行を管理する。例えば、端末装置やネットワークなどから受け取った処理要求に対して、必要な処理を実行し、その結果を返すような、何らかの手段で起動された処理を実行する流れをトランザクションと呼ぶ。個々のトランザクションは、実行過程で、１または複数のファイル（あるいはデータベース）に記録管理するデータの更新を行う。トランザクション処理システムは、このような１または複数のデータの更新を、アトミックにコミットするかアボートするかのいずれかの状態にすることを保証する。すなわち、すべての更新を同時に有効にするのがコミットである。逆に、すべての更新を捨ててトランザクションを実行しなかったのと同じ状態に戻すのがアボートである。また、トランザクション処理システムは、一度トランザクションをコミットしたら、そのトランザクションによる更新が取り消されることがないことも保証する。
【０００３】
このようなトランザクション処理システムを実現する方式は広く知られており、例えば“ＴＲＡＮＳＡＣＴＩＯＮ ＰＲＯＣＥＳＳＩＮＧ： ＣＯＮＣＥＰＴＳ ＡＮＤ ＴＥＣＨＮＩＱＵＥＳ”（Ｊｉｍ Ｇｒａｙ，Ａｎｄｒｅａｓ Ｒｅｕｔｅｒ著、Ｍｏｒｇａｎ Ｋａｕｆｍａｎｎ）にはさまざまな方式が開示されている。
【０００４】
トランザクション処理システムにおいて扱いが難しいのは、１つのファイル上のデータを、同時に複数のトランザクションが更新する場合である。１つのファイルには同時に１つのトランザクションしか更新することを許さなければ問題は生じない。しかし、同時に複数のトランザクションを並行に処理して性能を向上させるためには、同時に１つのファイルの中の異なる部分に記録管理するデータを更新できるようにすることが必要になる。この問題は、ファイルではなくデータベースを用いる場合も同様である。以下、ファイルを例に説明するが、データベースにおいても同様である。
【０００５】
このような並行に更新処理を行うトランザクション処理システムを実現するために従来から広く用いられているのは、ＷＡＬ（Ｗｒｉｔｅ Ａｈｅａｄ Ｌｏｇｇｉｎｇ）と呼ばれる方式である。この方式は、メモリ上のバッファに読み込んだファイルに対し、複数のトランザクションが更新を行った場合、ログファイルにはどのトランザクションがどのファイルのどの部分をどう書き換えたかを記録する。さらに、ログに記録した更新情報が安定記憶装置（例えばハードディスク）上に書かれて消えないことが保証されるまで、バッファ上で行った更新はハードディスクなどの記憶媒体上の元のファイルには書き戻さないようにタイミングを制御する。
【０００６】
ＷＡＬ方式ではすべての更新履歴はログに記録されており、システムの障害が発生した場合には、そのログを使ってファイルを正しい状態に戻すことができる。すなわち、障害が発生してシステムを再起動した場合、トランザクション処理システムはログを見て、コミットしたトランザクションが行った更新で、それがファイルに反映されていないものは正しく反映させる。また、アボートしたトランザクションによる更新がファイルに書きこまれていたらそれを取り消す処理を行う。このようなリカバリ処理により、障害発生に対してもトランザクションの原子性（Ａｔｏｍｉｃｉｔｙ）や耐久性（Ｄｕｒａｂｉｌｉｔｙ）や分離性（Ｉｓｏｌａｔｉｏｎ）や一貫性（Ｃｏｎｓｉｓｔｅｎｃｙ）を保証することができる。
【０００７】
トランザクション処理システムを実現するもう１つの方式は、シャドウページ方式である。この方式でファイルを更新する場合には、ハードディスク上に、更新前のファイルが書き込まれているページと、更新後のファイルが書き込まれているページの両方を用意し、トランザクションのコミット時にファイルの管理データをアトミックに入れ替える。そのため、常にハードディスク上には正しいファイルが存在することが保証できる。
【０００８】
【発明が解決しようとする課題】
従来のＷＡＬ方式によるトランザクション処理方式では、トランザクションがファイルを更新する場合、まず更新内容をログに書いてからファイル本体を更新するため、複数のトランザクションによるファイルの共有を管理するためには複雑な処理手順を必要とする。また、１回の更新に対して、ログとファイル本体への２回の書き込み処理が必要になる。また、リカバリに必要な更新情報をログに記録し、リカバリ時にそのログを使ってファイルを一貫性のある状態に戻す処理は、複雑な処理手順を必要とする。さらに、リカバリ処理は障害発生後の再起動時に集中して行わなければならず、再起動に時間がかかるという問題点がある。
【０００９】
一方、シャドウページ方式では、ハードディスク上には常に正しい状態のファイルが存在するので、障害発生時のリカバリ処理のオーバヘッドが小さいという特徴を持つ。しかし、シャドウページ方式は、１つのトランザクションのコミット前とコミット後の２つのファイルのデータが記録されたページを、アトミックに交換することを基本操作としている。そのため、複数のトランザクションが同じファイルを更新したい場合には、それらのトランザクションをシリアライズして順に更新して行くようにしなければならない。ＷＡＬ方式のように同じファイルの異なる部分を複数のトランザクションが並行して更新できるようにするためにはシャドウページ方式だけでは無理で、その上にＷＡＬ方式と同じようにログを使ったデータの管理をするなどの工夫が必要になる。そのため、シャドウページ方式は簡単に実装できても、その上に複雑なデータの管理を実装することが必要になるという問題点がある。
【００１０】
本発明は、上記事情を考慮してなされたもので、並行に動作する複数のトランザクションによるファイルの更新処理と障害時のリカバリ処理を簡単に効率良く実現することのできるトランザクション処理方法及びトランザクション処理システムを提供することを目的とする。
【００１１】
【課題を解決するための手段】
本発明は、各トランザクションがそれぞれ１以上のファイルを更新対象とするトランザクション処理システムのトランザクション処理方法であって、複数のトランザクションが同時に更新対象としているファイルの各々について、当該ファイルのファイル識別情報と当該ファイルを同時に更新対象としている複数のトランザクションのトランザクション識別情報との対応を記録した第１の管理表を記憶する第１のステップと、一つのトランザクションが占有して更新対象としているファイルの各々について、当該ファイルのファイル識別情報と当該ファイルを更新対象としている一つのトランザクションのトランザクション識別情報との対応を記録した第２の管理表を記憶する第２のステップと、複数のトランザクションが同時に更新対象としているファイルごとに、それぞれ、安定記憶装置からバッファ領域上に読み出した同一のファイルを更新対象として複数のトランザクションが処理を行う第３のステップと、前記複数のトランザクションのうちの一つのトランザクションのコミット時に、当該一つのトランザクションのトランザクション識別情報に基づき前記第１の管理表を参照して、当該一つのトランザクションが同時に更新対象としているファイルのファイル識別情報を求め、求めたファイル識別情報に係るファイルそれぞれについて、当該一つのコミットするトランザクションによる確定した更新内容と、他のコミットしていないトランザクションによる未確定の更新内容と、該未確定の更新を取り消すための情報とをファイル内容として含む前記ファイルを、安定記憶装置に書き込むことを、同期して行う第４のステップとを有し、前記第４のステップにおいては、更に、前記一つのトランザクションのトランザクション識別情報に基づき前記第２の管理表を参照し、当該一つのトランザクションが前記ファイルとは別のファイルを占有して更新対象として前記バッファ領域上で処理を行っていた場合には、前記ファイルの前記安定記憶装置への書き込みと同期させて、当該一つのトランザクションによる前記別のファイルに対する確定した更新内容をファイル内容として含む前記別のファイルを前記安定記憶装置に書き込むことを特徴とする。
【００１２】
安定記憶装置とは、例えば、ハードディスク等の、電源を切っても記憶した内容が消えない記憶装置を指す。
【００１３】
本発明では、上記のように、あるトランザクションのコミット時に、そのトランザクションが更新したファイルを別のトランザクションも更新している場合には、その別のトランザクションによる更新内容とそれを取り消すための情報も一緒にファイルの中身に書き込んで、そのファイルを安定記憶装置（例えばハードディスク）に書き出すことにより、ファイルとは別にログを用意して複雑な管理を行うようなことをしなくとも、トランザクションの原子性（トランザクション単位で、行った更新の全てが安定記憶装置上で有効になる（コミット）か全て無効になる（アボート）かいずれかの状態にしかならないことを、システムに障害が起きた場合でも保証できること）を担保しつつ、一つのファイルのデータを複数のトランザクションが並行して更新することを実現できる。
【００１４】
好ましくは、前記他のコミットしていないトランザクションをコミットする時には、該他のこれからコミットするトランザクションによる新たに確定した更新内容と、以前にコミットしたトランザクションによる既に確定している更新内容のうち該他のこれからコミットするトランザクションによる新たに確定した更新内容とは競合しないものとをファイル内容として含むファイルを、前記安定記憶装置に格納された前記ファイルに上書きするようにしてもよい。
【００１５】
あるトランザクションがコミットした後、同じファイルを更新している別のトランザクションをコミットする場合には、後にコミットするトランザクションの更新内容と、先にコミットしたトランザクションの更新内容のうち後にコミットするトランザクションによって書き換えられてはいないものとを書き込んだファイルで、先に安定記憶装置に書き出されたファイル（後にコミットすることになるトランザクションの更新内容とそれを取り消すための情報が入っている）を上書きすれば、トランザクションの原子性を担保できる。なお、あるトランザクションがコミットした後、同じファイルを更新している別のトランザクションをアボートする場合には、アボートするトランザクションによる更新がなかった状態に戻したファイルで、先に安定記憶装置に書き出されたファイル（後にアボートすることになるトランザクションの更新内容とそれを取り消すための情報が入っている）を上書きしても良いし、アボート時には何もしなくとも、下記のように次にファイルを読み出す時にリカバリ処理を行えば、トランザクションの原子性は担保できる。
【００１６】
好ましくは、新しくファイルを前記安定記憶装置から読み出した時に、このファイルに、コミットしていないトランザクションによる未確定の更新内容および該未確定の更新を取り消すための情報が含まれているか否かを調べ、含まれている場合には、読み出した前記ファイルを前記情報を用いて前記コミットしていないトランザクションによる更新がなかった状態に戻すようにしてもよい。
【００１７】
あるトランザクションがコミットした後、同じファイルを更新している別のトランザクションのコミット／アボートが行われる前に、システムに障害が起きた場合でも、コミットしたトランザクションによる更新は既に安定記憶装置上でファイルに正しく反映されている。これに加えて上記のようなリカバリ処理を行えば、未確定の（別の）トランザクションによる更新はアボートしたものとしてそれを取り消すことができるので、トランザクションの一貫性が保たれる。しかも、このリカバリ処理は、障害回復時に行う必要はなく、次にそのファイルを読み出した時に行えば良い。
【００１８】
好ましくは、前記一つのコミットするトランザクションが前記ファイルとは別のファイルをも更新対象として前記バッファ領域上で処理を行っていた場合には、前記ファイルの前記安定記憶装置への書き込みと同期させて、該一つのコミットするトランザクションによる前記別のファイルに対する確定した更新内容をファイル内容として含む前記別のファイルを前記安定記憶装置に書き込むようにしてもよい。
【００１９】
上記のように複数のファイルの書き込みを同期させれば、一つのトランザクションがその処理開始時からコミット時までに複数のファイルに対して行った更新の全てが安定記憶装置上で有効になる（コミット）か、全てが無効になる（アボート）か、いずれかの状態にしかならない（システムに障害が起きた場合でも、一つのトランザクションが行った更新のうち一部分だけが有効になり残りが無効になるということはあり得ない）ことを保証するような、アトミックな書き込みが実現できる。
【００２０】
好ましくは、前記ファイルは、一纏まりの情報を分割して記録した複数個のファイルの集合の中の一つのファイルであるようにしてもよい。
【００２１】
好ましくは、一纏まりの情報を分割して記録した複数個のファイルの集合に対して二つ以上のトランザクションが前記バッファ領域上で更新を行い、この二つ以上のトランザクションによる更新内容に基づいて、前記バッファ領域上で、新しいファイルの追加、ファイル間の情報の移動および不要ファイルの削除のうち少なくとも一つを行うことにより、前記複数個のファイルそれぞれの大きさが予め定められた基準に従うように調整し、前記一つのコミットするトランザクションが更新したファイル、および該トランザクションによる更新に伴う前記調整の結果更新あるいは新規に作成されたファイルのうち、少なくとも一つのファイルに対して他のトランザクションが更新を行っている場合には、該少なくとも一つのファイルを更新対象（すなわち前記ファイル）として複数のトランザクションが処理を行ったものとして、前記ファイルの前記安定記憶装置への書き込みを行うようにしてもよい。
【００２２】
また、本発明は、各トランザクションがそれぞれ１以上のファイルを更新対象とするトランザクション処理システムであって、複数のトランザクションが同時に更新対象としているファイルの各々について、当該ファイルのファイル識別情報と当該ファイルを同時に更新対象としている複数のトランザクションのトランザクション識別情報との対応を記録した第１の管理表を記憶する手段と、一つのトランザクションが占有して更新対象としているファイルの各々について、当該ファイルのファイル識別情報と当該ファイルを更新対象としている一つのトランザクションのトランザクション識別情報との対応を記録した第２の管理表を記憶する手段と、複数のトランザクションが同時に更新対象としているファイルを、それぞれ、安定記憶装置からバッファ領域上に読み出す手段と、複数のトランザクションが同時に更新対象としているファイルごとに、それぞれ、当該ファイルに対して複数のトランザクションのそれぞれが行った更新の内容と該更新を取り消すための情報とを前記バッファ領域上で該ファイル内に書き込む手段と、前記複数のトランザクションのうちの一つのトランザクションのコミット時に、当該一つのトランザクションのトランザクション識別情報に基づき前記第１の管理表を参照して、当該一つのトランザクションが同時に更新対象としているファイルのファイル識別情報を求め、求めたファイル識別情報に係るファイルそれぞれについて、当該ファイル内に書き込まれた該一つのコミットするトランザクションによる更新の内容については該更新を取り消すための情報を削除することにより確定させ、前記ファイル内に書き込まれた他のコミットしていないトランザクションによる更新の内容および該更新を取り消すための情報についてはそのままとし、確定させた内容とそのままとした情報とをファイル内容として含む前記ファイルを、前記安定記憶装置に書き出すことを、同期して行う制御手段とを備え、前記制御手段は、前記一つのトランザクションが前記ファイルとは別のファイルを占有して更新対象として前記バッファ領域上で処理を行っていた場合には、前記ファイルの前記安定記憶装置への書き込みと同期させて、当該一つのトランザクションによる前記別のファイルに対する確定した更新内容をファイル内容として含む前記別のファイルを前記安定記憶装置に書き込むことを特徴とする。
【００２４】
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
【００２５】
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。
【００２６】
本発明によれば、並行に動作する複数のトランザクションによるファイルの更新を、簡単な処理手順で実現することができる。本発明によれば、従来のＷＡＬ方式や、シャドウページ方式の上に特殊なログ管理を実装するときのように、データの更新時やコミット処理時あるいはリカバリ時に複雑な処理を必要としない。
【００２７】
また、本発明では、障害発生後のリカバリ処理を、再起動時に集中して行う必要は無く、障害で更新途中の状態は次にそのファイルを使う時点で行われるため、リカバリ処理のオーバヘッドが小さい。
【００２８】
さらに、本発明では、１つのデータを複数のファイルに分けて管理することで、ファイルの更新のコミット時にディスクに書き戻すデータの量を減らすことができる。
【００２９】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【００３０】
最初に従来のファイルシステムについて簡単に説明する。図４３に、従来のトランザクション処理システムの例を示す。従来のトランザクション処理システムでは、トランザクションを処理するアプリケーションプログラム１０１は、データベース管理システム１０２を介してデータの操作を行う。ファイルシステム１０３はハードディスク１０４などの安定記憶装置に記録したファイルの操作や管理を行う。データベース管理システム１０２は、ファイルシステム１０３の管理するファイルを使って、アプリケーションプログラム１０１が必要とするデータを管理する。複数のアプリケーションプログラム１０１が共有しているデータに対する操作の間の並行制御もデータベース管理システム１０２が行う。
【００３１】
図１に、本発明の一実施形態に係るトランザクション処理システムの構成例を示す。
【００３２】
なお、本実施形態では、安定記憶装置としてハードディスクを用いるものとして説明するが、もちろん安定記憶装置として他の装置を使用することも可能である。また、本実施形態では、ユーザプログラムによりトランザクションが発生するものとして説明するが、もちろんユーザプログラム以外のものがトランザクションを発生させる場合も同様である。
【００３３】
本実施形態のトランザクション処理システムでは、図１に示されるように、トランザクションを実行する複数のアプリケーションプログラム２間で共有するファイルの操作は、共有データ管理部４を介して行い、共有しないファイルの操作は、アプリケーションプログラム２がファイルシステム６を直接指示して行う。
【００３４】
トランザクションマネージャ８は、各アプリケーションプログラム２が処理するトランザクションの管理を行う。アプリケーションプログラム２は、トランザクションの処理を開始する時点で、トランザクションマネージャ８からトランザクション識別子を割り付けてもらう。以降、トランザクションの処理を進めて行く過程で、共有データ管理部４やファイルシステム６に操作を指示するときには、トランザクション識別子を提示してどのトランザクションによるファイルの更新であるかを知らせる。アプリケーションプログラム２がトランザクションの処理の終了をトランザクションマネージャ８に伝えると、トランザクションマネージャ８は共有データ管理部４やファイルシステム６に対して、トランザクション識別子で指定したトランザクションによるファイルの更新結果をハードディスク１０に書き込んでコミットするか、あるいは更新結果を廃棄してアボートするかを指示する。
【００３５】
なお、トランザクションマネージャ８を用いず、ユーザプログラム２が自分でトランザクション識別子に相当する情報を生成したり、コミット（ＣＯＭＭＩＴ）やアボート（ＡＢＯＲＴ）を指示するように実施することもできる（本実施形態では、トランザクションマネージャ８を用いる場合について説明する）。
【００３６】
共有データ管理部４は、複数のトランザクションによる同一ファイルの異なる部分の更新を実現する。共有データ管理部４は、（当該共有データ管理部４を介して）どのファイルがどのトランザクションによって更新されているかを、更新管理表４１を用いて管理している。図２に、更新管理表４１の例を示す。更新管理表４１には、ファイル名と、そのファイルを更新中のトランザクションのトランザクション識別子のリストの対応が記録されている。図２では、例えば、Ｆ０１０２というファイルはトランザクション識別子が３６，２１，５の３つのトランザクションによって更新中であることを示している。
【００３７】
ファイルシステム６は、トランザクションによるファイルの操作を実現する部分である。ファイルシステム６は、バッファ領域６２を管理するバッファ管理部（図示せず）とトランザクション管理表６１を持っている。ハードディスク１０に記録しているファイルを読んだり更新したりする場合には、そのファイルをバッファ領域６２に読み出してきて、バッファ領域６２上で読んだり更新したりする。新しくファイルを作成する場合には、まずバッファ領域６２にファイルを作成する。バッファ領域６２上で更新や作成されたファイルは、トランザクションのコミット時にハードディスク１０に書き込む。トランザクション管理表６１は、どのトランザクションがどのファイルを更新しているかを管理している。
【００３８】
図３に、トランザクション管理表６１の例を示す。トランザクション管理表６１には、トランザクション識別子と、そのトランザクションが更新中のファイルのリストの対応が記録されている。図３の例では、トランザクション識別子“３”のトランザクションはファイルＦ９２６８のみを更新しており、トランザクション識別子“５”のトランザクションはファイルＦ０１００とＦ９２６４の２つのファイルを更新していることを示している。トランザクション管理表６１の最後のエントリは、どのトランザクションにも属していないファイルの更新を管理している。
【００３９】
図３に例示したトランザクション管理表６１では、最後の行のトランザクション“ＮＯＴＸ”のエントリがこれに当たる。この例では、ファイルＦ０１０２，Ｆ２１５６，Ｆ３６２４，Ｆ５４９７，Ｆ７５３１は特定のトランザクションの一部として更新されているのではなく、どのトランザクションとも関連せずに更新されていることを示す。以下で説明するように、共有データ管理部４を介して更新中のファイルは、どのトランザクションとも関連しない状態で更新するので、このエントリに記録される。なお、このエントリに記録されるファイルがどのトランザクションによって更新されているかは、共有データ管理部４の更新管理表４１を参照すれば知ることができる。
【００４０】
以下は、データの一例としてＸＭＬドキュメントの形式での情報を例にとり、共有データ管理部４を介して、このＸＭＬドキュメントの形式で情報が記録されているファイルを更新するトランザクション処理システムに本発明を適応した場合についてより具体的に説明する。
【００４１】
なお、ＸＭＬに関しては、“Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ （ＸＭＬ） １．０”（Ｗ３Ｃ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ １０−Ｆｅｂ−９８）に開示されている。
【００４２】
この場合、トランザクション処理システムでは、「キー」とそれに対する「値」のペアの集合を、ＸＭＬのドキュメントの形式でファイルに記録して管理している。このドキュメントは、キーを指定してその値を検索するという、一般的なデータベースとして使用することができる。
【００４３】
図４に、そのようなドキュメントの一例を示す。
この例のＸＭＬドキュメントでは、＜ｋｅｙ＞と＜／ｋｅｙ＞のタグで囲まれた部分に「キー」を保持し、＜ｖａｌｕｅ＞と＜／ｖａｌｕｅ＞のタグで囲まれた部分に「値」を保持し、そのペアを＜ｅｎｔｒｙ＞と＜／ｅｎｔｒｙ＞のタグで囲んだエントリを作り、それらが複数集まったものを、最も外の＜ＫＶｔａｂｌｅ＞と＜／ＫＶｔａｂｌｅ＞のタグが囲んでいる。実際には、ＸＭＬドキュメントは先頭部分に＜？ｘｍｌ＞で始まるプロローグ部を持つが、ここでは省略する。なお、ＸＭＬの用語として、＜ｋｅｙ＞のような開始タグと、＜／ｋｅｙ＞のようなそれに対応する終了タグで囲まれた部分を、エレメントと呼ぶ。
【００４４】
図４に例示したＸＭＬドキュメントでは、キー「ＡＰＰＬＥ」に対応する値は「４００円」であり、キー「ＢＩＳＣＵＩＴ」に対応する値は「２５０円」であり、キー「ＣＨＯＣＯＬＡＴＥ」に対応する値は「２００円」であり、キー「ＧＲＡＰＥ」に対応する値は「６００円」になっている。
【００４５】
このＸＭＬドキュメントのファイルに対して、トランザクションを実行するアプリケーションプログラム２およびトランザクションマネージャ８は、共有データ管理部４を介して、ＲＥＡＤ（ｔｘｉｄ，ｋｅｙ）とＵＰＤＡＴＥ（ｔｘｉｄ，ｋｅｙ，ｖａｌｕｅ）とＲＥＭＯＶＥ（ｔｘｉｄ，ｋｅｙ）とＣＯＭＭＩＴ（ｔｘｉｄ）とＡＢＯＲＴ（ｔｘｉｄ）の５種類の操作ができるものとする。本実施形態では、ＲＥＡＤ、ＵＰＤＡＴＥ、ＲＥＭＯＶＥはアプリケーションプログラム２が指示し、ＣＯＭＭＩＴとＡＢＯＲＴはトランザクションマネージャ８が指示するものとする。なお、前述したように、トランザクションマネージャ８が存在せず、アプリケーションプログラム２がＣＯＭＭＩＴやＡＢＯＲＴも指示するように実施することもできる。
【００４６】
ＲＥＡＤ（ｔｘｉｄ，ｋｅｙ）は、ｔｘｉｄで指定したトランザクション識別子を持つトランザクションが、ｋｅｙで指定したエントリの値を読み出す操作である。
【００４７】
ＵＰＤＡＴＥ（ｔｘｉｄ，ｋｅｙ，ｖａｌｕｅ）は、ｔｘｉｄで指定したトランザクション識別子を持つトランザクションが、ｋｅｙで指定したエントリの値をｖａｌｕｅで指定した値に更新する操作である。ｋｅｙで指定したエントリが無い場合には、新しくエントリを作成する。
【００４８】
ＲＥＭＯＶＥ（ｔｘｉｄ，ｋｅｙ）は、ｔｘｉｄで指定したトランザクション識別子を持つトランザクションが、ｋｅｙで指定したエントリを削除する操作である。
【００４９】
ＣＯＭＭＩＴ（ｔｘｉｄ）は、ｔｘｉｄで指定したトランザクション識別子を持つトランザクションが行ったファイルの内容の変更を、ディスク上のファイルに書き戻して、変更を永久的なものにする。
【００５０】
ＡＢＯＲＴ（ｔｘｉｄ）は、ｔｘｉｄで指定したトランザクション識別子を持つトランザクションが行ったファイルの内容の変更を、すべて取り消して無かったものにする。
【００５１】
これらの５つの操作のうち、ＲＥＡＤはファイルの内容を変更しない操作であるのに対し、ＵＰＤＡＴＥとＲＥＭＯＶＥはファイルの内容を変更する操作である。ＣＯＭＭＩＴとＡＢＯＲＴは、トランザクションの処理結果をコミットすなわち正しく完了した状態にするか、アボートすなわち処理結果をキャンセルして処理開始前の状態にする操作である。
【００５２】
図４のＸＭＬドキュメントに対して、３つのトランザクション（ｔｘｉｄ＝１のトランザクション（１）、ｔｘｉｄ＝２のトランザクション（２）、ｔｘｉｄ＝３のトランザクション（３）とする）が、以下に示すように並行にアクセスする場合の動作を例に、本実施形態のトランザクション処理システムの動作を説明する。
［１］ ＵＰＤＡＴＥ（１，ＩＣＥＣＲＥＡＭ，４５０円）
［２］ ＵＰＤＡＴＥ（３，ＡＰＰＬＥ，５００円）
［３］ ＲＥＭＯＶＥ（２，ＢＩＳＣＵＩＴ）
［４］ ＵＰＤＡＴＥ（２，ＣＨＯＣＯＬＡＴＥ，３００円）
［５］ ＲＥＭＯＶＥ（１，ＧＲＡＰＥ）
［６］ ＵＰＤＡＴＥ（２，ＫＩＷＩＦＲＵＩＴ，３００円）
［７］ ＣＯＭＭＩＴ（３）
［８］ ＣＯＭＭＩＴ（１）
［９］ ＡＢＯＲＴ（２）
本トランザクション処理システムが図４のファイルを更新する場合、まず、共有データ管理部４から指示されたファイルシステム６が、ハードディスク１０にあるファイルの内容をバッファ領域６２に読み出す。トランザクションがコミットするまでは、ファイルの更新はバッファ領域６２にあるコピーに対してのみ行い、ハードディスク１０には書き戻さない。
【００５３】
［１］最初に、ＵＰＤＡＴＥ（１，ＩＣＥＣＲＥＡＭ，４５０円）で、トランザクション（１）がキー「ＩＣＥＣＲＥＡＭ」を追加してその値を「４５０円」にする。このとき、ファイルがまだバッファ領域６２に無ければ読み込む。その後、バッファ上のデータに対して、図５に示すようにバッファ領域６２のデータを変更する。ここでは、新しい「ＩＣＥＣＲＥＡＭ」をキーにするエントリを追加し、その値を「４５０円」にする。さらに、このエントリがトランザクション（１）によって更新中であることを示すために、＜ｅｎｔｒｙ＞タグの属性としてＴＸＩＤとＴＸＳＴＡＴＥの２つを記録しておく。属性ＴＸＩＤの値には変更を行ったトランザクションのトランザクション識別子を、属性ＴＸＳＴＡＴＥには変更の種類を記録しておき、ＣＯＭＭＩＴあるいはＡＢＯＲＴの処理時にこの情報を使用する。ここでは、ＴＸＩＤ属性の値としてトランザクション識別子「１」と、ＴＸＳＴＡＴＥ属性の値として更新中を示す「ＵＰＤＡＴＥ」を持たせる。
【００５４】
［２］続いて、ＵＰＤＡＴＥ（３，ＡＰＰＬＥ，５００円）で、トランザクション（３）がキー「ＡＰＰＬＥ」の値を「５００円」に変更する。このときは、バッファ領域６２のデータを図６に示すように変更する。ここでは、「ＡＰＰＬＥ」をキーにするエントリの＜ｖａｌｕｅ＞タグを＜ｏｌｄｖａｌｕｅ＞タグに変更して残しておき、新しい値「５００円」を＜ｖａｌｕｅ＞タグで囲ったエレメントを作成してエントリに追加する。さらに、エントリのには、ＴＸＩＤ属性の値としてトランザクション識別子「３」と、ＴＸＳＴＡＴＥ属性の値として更新中を示す「ＵＰＤＡＴＥ」を持たせる。
【００５５】
［３］次に、ＲＥＭＯＶＥ（２，ＢＩＳＣＵＩＴ）で、トランザクション（２）がキー「ＢＩＳＣＵＩＴ」のエントリを削除する。このときは、バッファ領域６２のデータを図７に示すように変更する。ここでは、「ＢＩＳＣＵＩＴ」をキーにするエントリの、ＴＸＩＤ属性の値にトランザクション識別子「２」を、ＴＸＳＴＡＴＥ属性の値に削除されたことを示す「ＲＥＭＯＶＥ」を持たせる。
【００５６】
［４］次に、ＵＰＤＡＴＥ（２，ＣＨＯＣＯＬＡＴＥ，３００円）でトランザクション（２）がキー「ＣＨＯＣＯＬＡＴＥ」の値を３００円に変更した後のバッファ領域６２のデータは、これまでと同様の処理を行って図８のようになる。
【００５７】
［５］次に、ＲＥＭＯＶＥ（１，ＧＲＡＰＥ）でトランザクション（１）がキー「ＧＲＡＰＥ」のエントリを削除した後のバッファ領域６２のデータは、これまでと同様の処理を行って図９のようになる。
【００５８】
［６］次に、ＵＰＤＡＴＥ（２，ＫＩＷＩＦＲＵＩＴ，３００円）でトランザクション（２）がキー「ＫＩＷＩＦＲＵＩＴ」に対応するエントリを追加してその値を「３００円」にした後のバッファ領域６２のデータは、これまでと同様の処理を行って図１０のようになる。
【００５９】
［７］続いて、ＣＯＭＭＩＴ（３）でトランザクション（３）のコミット処理が起動される。
【００６０】
このように複数のトランザクションが同じファイルを更新している場合のコミット処理の方式について説明する。
【００６１】
図１０のようにファイルのデータがバッファ領域６２上で変更されている状態で、ＣＯＭＭＩＴ（３）でトランザクション（３）のコミット処理が起動されたとする。このとき、図１１に示すように、トランザクション（３）による変更を、エレメントにＴＸＩＤやＴＸＳＴＡＴＥがついたり＜ｏｌｄｖａｌｕｅ＞タグを持っている一時的な状態から、それらを削除してハードディスク１０に書き戻しても良い正しく更新された状態に変更する。こうしてトランザクション（３）の変更を反映したファイルのデータができると、それを書き戻してハードディスク１０にある元のファイルを置き換える。このとき、本実施形態では、トランザクション（１）やトランザクション（２）による変更途中の状態のデータは、その変更途中のままハードディスク１０に書き戻すことができる（後述するように、変更途中の状態のデータにはその更新を取り消すのに必要な情報を付加しているので、次に読み出したときに更新を取り消すための処理を行うことができる）。
【００６２】
［８］次に、ＣＯＭＭＩＴ（１）でトランザクション（１）のコミット処理が起動されたとする。このとき、図１２に示すように、トランザクション（１）による変更を反映させ、それをハードディスク１０に書き戻す。
【００６３】
［９］次に、ＡＢＯＲＴ（２）でトランザクション（２）がアボートしたとする。このとき図１３に示すように、バッファ領域６２にあるファイルのデータからトランザクション（２）による変更を取り消す。
【００６４】
以下では、これまでの例で説明した各々の操作の処理手順を説明する。
【００６５】
まず、ＲＥＡＤの処理手順について説明する。
【００６６】
ＲＥＡＤの操作は指定されたキーに対応するエントリの値を読み出すだけなので簡単である。ただし、ＲＥＡＤの実装には、そのシステムの使い方に応じて２通りの場合がある。他のトランザクションが更新中でなければ値を読み出せるという点に関しては共通であるが、あるトランザクションが読み出したエントリを、そのトランザクションが終了する前に他のトランザクションが更新できるか否かで２通りの方式に分かれる。つまり、１つの方式は、更新できるという解釈で、ＲＥＡＤに関しては何の排他制御もしないという方式である。もう１つの方式は、更新できないと言う解釈で、広く知られたＲＥＡＤ／ＷＲＩＴＥロックのセマンティクスに従って排他制御する方式である。すなわち、同じトランザクションによるＲＥＡＤと更新は両立するが、異なるトランザクションによるＲＥＡＤと更新は両立せず、また、異なるトランザクションのＲＥＡＤどうしは両立するというものである。排他制御をする後者の方式は、排他制御をしない前者の方式を包含するので、ここでは後者の方式の場合の処理手順を説明する。排他制御しない前者の方式は、後者の方式においてＲＥＡＤについては何も制御しないのと等価である。
【００６７】
図１４にＲＥＡＤ（ｔｘｉｄ，ｋｅｙ）の処理手順の一例を示す。
【００６８】
まず、キーの値がｋｅｙに指定されたものと同じエントリを探す（ステップＳ１１）。
【００６９】
エントリが見つかったならば（ステップＳ１２）、そのエントリにＴＸＳＴＡＴＥ属性が付いているか否か、またＴＸＳＴＡＴＥ属性が付いているならばそのＴＸＳＴＡＴＥ属性が「ＲＥＡＤ」「ＵＰＤＡＴＥ」「ＲＥＭＯＶＥ」のいずれであるかを調べる（ステップＳ１３）。
【００７０】
ＴＸＳＴＡＴＥ属性が付いていない場合は、誰もアクセスしていないので、そのエントリにＴＸＩＤ属性とＴＸＳＴＡＴＥ属性を付け、ＴＸＩＤ属性の値は「ｔｘｉｄ」に、ＴＸＳＴＡＴＥ属性の値は「ＲＥＡＤ」にし（ステップＳ１４）、＜ｖａｌｕｅ＞部の値を結果として返す（ステップＳ１５）。
【００７１】
ＴＸＳＴＡＴＥ属性の値が「ＲＥＡＤ」の場合は、そのＴＸＩＤ属性にまだ「ｔｘｉｄ」が入っていなければ追加し（ステップＳ１６，Ｓ１７）、＜ｖａｌｕｅ＞部の値を結果として返す（ステップＳ１８）。
【００７２】
ＴＸＳＴＡＴＥ属性の値が「ＵＰＤＡＴＥ」の場合は、同じトランザクションが変更した値であれば読めるので（ステップＳ１９）、＜ｖａｌｕｅ＞部の値を結果として返す（ステップＳ２０）。そうでない場合には、他のトランザクションが使用中で読めないことを知らせる。
【００７３】
ＴＸＳＴＡＴＥ属性の値が「ＲＥＭＯＶＥ」ならば（ステップＳ１３）、無いものを読もうとしているのでエラーになる。
【００７４】
なお、エントリが見つからなかったならば（ステップＳ１２）、エラーとなる。
【００７５】
図１５に、図４の状態のファイルのデータに対して、ＲＥＡＤ（４，ＣＨＯＣＯＬＡＴＥ）でトランザクション４がキー「ＣＨＯＣＯＬＡＴＥ」の値を読み出した直後のバッファ領域６２上のデータの状態を示す。
【００７６】
通常、ＴＸＩＤの値はトランザクション識別子を１つ持っているが、ＴＸＳＴＡＴＥ属性の値が「ＲＥＡＤ」の場合のＴＸＩＤ属性にはトランザクション識別子のリストを持つことが出来る。これは、複数のトランザクションが同時に読み出すことが出来るためである。例えば、トランザクション識別子が１と４と５のトランザクションがＲＥＡＤしている場合、そのＴＸＩＤ属性の値は「１ ４ ５」のようなリストになっている。
【００７７】
次に、ＵＰＤＡＴＥの処理手順について説明する。
【００７８】
図１６に、ＵＰＤＡＴＥ（ｔｘｉｄ，ｋｅｙ，ｖａｌｕｅ）の処理手順の一例を示す。
【００７９】
まず、キーの値がｋｅｙに指定されたものと同じエントリを探す（ステップＳ２１）。
【００８０】
エントリが見つかったならば（ステップＳ２２）、そのエントリにＴＸＳＴＡＴＥ属性が付いているか否か、またＴＸＳＴＡＴＥ属性が付いているならばそのＴＸＳＴＡＴＥ属性が「ＲＥＡＤ」「ＵＰＤＡＴＥ」「ＲＥＭＯＶＥ」のいずれであるかを調べる（ステップＳ２３）。
【００８１】
ＴＸＳＴＡＴＥ属性が付いていない場合は、誰もアクセスしていないので、そのエントリにＴＸＩＤ属性とＴＸＳＴＡＴＥ属性を付け、ＴＸＩＤ属性の値は「ｔｘｉｄ」に、ＴＸＳＴＡＴＥ属性の値は「ＵＰＤＡＴＥ」にし、現在の＜ｖａｌｕｅ＞部のタグ名を＜ｏｌｄｖａｌｕｅ＞に変更して退避し、新しく＜ｖａｌｕｅ＞部を作ってその値をＵＰＤＡＴＥの第３引数のｖａｌｕｅに指定されたものにする（ステップＳ２４）。
【００８２】
ＴＸＳＴＡＴＥ属性の値が「ＲＥＡＤ」の場合は、同じトランザクションだけがＲＥＡＤしている場合に限って更新できる。この場合は（ステップＳ２５）、ＴＸＳＴＡＴＥ属性の値を「ＵＰＤＡＴＥ」に変更し、現在の＜ｖａｌｕｅ＞部のタグ名を＜ｏｌｄｖａｌｕｅ＞に変更して退避し、新しく＜ｖａｌｕｅ＞部を作ってその値をＵＰＤＡＴＥの第３引数のｖａｌｕｅに指定されたものにする（ステップＳ２６）。他のトランザクションがＲＥＡＤ中であれば、ＵＰＤＡＴＥすることができないので、使用中であることを知らせる。
【００８３】
ＴＸＳＴＡＴＥ属性の値が「ＵＰＤＡＴＥ」の場合は、同じトランザクションが更新したエントリであれば（ステップＳ２７）、その＜ｖａｌｕｅ＞部の値をＵＰＤＡＴＥの第３引数のｖａｌｕｅに指定されたものに変更する（ステップＳ２８）。他のトランザクションがＵＰＤＡＴＥ中であればＵＰＤＡＴＥすることができないので、使用中であることを知らせる。
【００８４】
ＴＸＳＴＡＴＥ属性の値が「ＲＥＭＯＶＥ」の場合は（ステップＳ２３）、無いものを更新しようとしているのでエラーになる。
【００８５】
なお、キーの値がｋｅｙに指定されたものと同じエントリが見つからない場合は（ステップＳ２２）、新しくエントリを作成し、＜ｋｅｙ＞部の値と＜ｖａｌｕｅ＞部の値を、それぞれＵＰＤＡＴＥの第２引数と第３引数に指定されたものにしたエントリを作成し、そのＴＸＩＤ属性の値を「ｔｘｉｄ」に、ＴＸＳＴＡＴＥ属性の値を「ＵＰＤＡＴＥ」にする（ステップＳ２９）。
【００８６】
次に、ＲＥＭＯＶＥの処理手順について説明する。
【００８７】
図１７に、ＲＥＭＯＶＥ（ｔｘｉｄ，ｋｅｙ）の処理手順の一例を示す。
【００８８】
まず、キーの値がｋｅｙに指定されたものと同じエントリを探す（ステップＳ３１）。
【００８９】
エントリが見つかったならば（ステップＳ３２）、そのエントリにＴＸＳＴＡＴＥ属性が付いているか否か、またＴＸＳＴＡＴＥ属性が付いているならばそのＴＸＳＴＡＴＥ属性が「ＲＥＡＤ」「ＵＰＤＡＴＥ」「ＲＥＭＯＶＥ」のいずれであるかを調べる（ステップＳ３３）。
【００９０】
ＴＸＳＴＡＴＥ属性が付いていない場合は、誰もアクセスしていないので、ＴＸＩＤ属性の値を「ｔｘｉｄ」に、ＴＸＳＴＡＴＥ属性の値を「ＲＥＭＯＶＥ」にする（ステップＳ３４）。
【００９１】
ＴＸＳＴＡＴＥ属性の値が「ＲＥＡＤ」の場合には、同じトランザクションだけがＲＥＡＤしている場合に限ってＲＥＭＯＶＥできる。この場合は（ステップＳ３５）、ＴＸＳＴＡＴＥ属性の値を「ＲＥＭＯＶＥ」に変更する（ステップＳ３６）。他のトランザクションがＲＥＡＤ中であればＲＥＭＯＶＥすることができないので、使用中であることを知らせる。
【００９２】
ＴＸＳＴＡＴＥ属性の値が「ＵＰＤＡＴＥ」の場合は、同じトランザクションが更新したエントリであれば（ステップＳ３７）、ＲＥＭＯＶＥできる。このとき、＜ｏｌｄｖａｌｕｅ＞部があるかどうかで、そのエントリがこのトランザクションで新しく作られたものか、以前から存在していたものかがわかる。＜ｏｌｄｖａｌｕｅ＞部が無い場合には（ステップＳ３８）、このトランザクションが作成したエントリなので、即座にエントリを削除してしまって良い（ステップＳ４０）。そうでない場合には（ステップＳ３８）、ＴＸＳＴＡＴＥ属性の値を「ＲＥＭＯＶＥ」に変更する（ステップＳ３９）。他のトランザクションがＵＰＤＡＴＥ中であれば（ステップＳ３７）、ＲＥＭＯＶＥすることができないので、使用中であることを知らせる。
【００９３】
ＴＸＳＴＡＴＥ属性の値が「ＲＥＭＯＶＥ」の場合は（ステップＳ３３）、無いものを削除しようとしているのでエラーになる。
【００９４】
なお、エントリが見つからなかったならば（ステップＳ３２）、エラーとなる。
【００９５】
次に、ＣＯＭＭＩＴの処理手順について説明する。
【００９６】
図１８に、ＣＯＭＭＩＴ（ｔｘｉｄ）の処理手順の一例を示す。
【００９７】
ＣＯＭＭＩＴの処理時には、ファイル中のすべてのエントリに対して図１８の手順で処理を行う。
【００９８】
まず、そのエントリのＴＸＳＴＡＴＥ属性の値を調べる（ステップＳ１０１）。
【００９９】
ＴＸＳＴＡＴＥ属性を持たない場合は、どのトランザクションもアクセスしていないので何もしなくて良い。
【０１００】
ＴＸＳＴＡＴＥ属性が「ＲＥＡＤ」の場合は、そのＴＸＩＤ属性の中にｔｘｉｄが含まれていて（ステップＳ１０２）、ｔｘｉｄ以外のトランザクション識別子も含まれていれば（ステップＳ１０３）、ｔｘｉｄを抜く（ステップＳ１０４）。ＴＸＩＤ属性がｔｘｉｄのみをもっている場合には（ステップＳ１０３）、ＴＸＩＤ属性とＴＸＳＴＡＴＥ属性を削除する（ステップＳ１０５）。
【０１０１】
次に、ＴＸＳＴＡＴＥ属性の値が「ＵＰＤＡＴＥ」の場合は、そのＴＸＩＤ属性の値がｔｘｉｄと同じであれば（ステップＳ１０６）、＜ｏｌｄｖａｌｕｅ＞部とＴＸＩＤ属性とＴＸＳＴＡＴＥ属性を削除してその更新を有効にする（ステップＳ１０７）。
【０１０２】
ＴＸＳＴＡＴＥ属性がＲＥＭＯＶＥの場合は（ステップＳ１０１）、そのＴＸＩＤ属性の値がｔｘｉｄと同じであれば（ステップＳ１０８）、そのエントリを削除する（ステップＳ１０９）。
【０１０３】
すべてのエントリに関して以上の処理が終了すれば、その時点のバッファ領域６２上のデータをハードディスク１０上に書き戻して、ファイルを更新する。
【０１０４】
ところで、ＣＯＭＭＩＴ処理の最後に、共有データ管理部４は、バッファ領域６２上で更新したファイルをハードディスク１０に書き込むように、ファイルシステム６に指示する。このとき、このファイルの書き込みは、コミットするトランザクションが更新した他のファイルと同期してアトミックに書き込む必要がある。すなわち、トランザクションを実行するアプリケーションプログラム２は、共有データ管理部４を介さずにファイルシステム６に直接指示して複数のファイルの更新を行っている可能性があり、また、共有データ管理部４を介しても複数のファイルを更新している可能性がある（図２および図３参照）。トランザクションとしてアトミックにコミットするためには、これらの複数のファイルへの更新がすべて完全に行われるなければならない。本実施形態のトランザクション処理システムでは、ファイルシステム６は、トランザクション管理表６１によって、アプリケーションプログラム２から直接指示されて更新したファイルのリストをトランザクション毎に管理しており、その情報を用いて、同じトランザクションが更新したファイルを一括してアトミックにハードディスク１０に書き戻すことができる。
【０１０５】
しかし、共有データ管理部４を介して操作しているファイルに関しては、ファイルシステム６内ではどのトランザクションとも関連しないファイルとして管理されている。それらのファイルをどのトランザクションのコミット時に書き戻せば良いかは、共有データ管理部４がＣＯＭＭＩＴの処理時に判断する。
【０１０６】
そこで、共有データ管理部４がどのトランザクションとも関連せずにオープンして更新したファイルに対して、特定のトランザクションのコミット時に同期してアトミックにハードディスク１０に書き戻すことを指示する機能を、ファイルシステム６に持たせる。ＣＯＭＭＩＴの処理を行う共有データ管理部４は、指定されたトランザクション識別子のトランザクションによる更新をファイルに反映させた後、そのファイルを指定されたトランザクション識別子のトランザクションと同期してハードディスク１０に書き戻すように、ファイルシステム６に指示する。ファイルシステム６は、このようにして指定されたファイルを、指定されたトランザクション識別子のトランザクションのコミット時に、トランザクション管理表６１にあるそのトランザクションが更新したファイルと同時に、アトミックにハードディスク１０に書き戻す。
【０１０７】
ただし、ファイルシステム６のコミット処理が終了後は、トランザクションを実行するアプリケーションプログラム２が直接ファイルシステム６に指示して更新したファイルの情報（トランザクション管理表６１のエントリやバッファ領域６２にあるファイルのイメージ）は不要になる。一方、共有データ管理部４が特定のトランザクションに関連せずに更新しているファイルは、その後も他のトランザクションによって更新が続けられるため、どのトランザクションとも関連しない状態のまま共有データ管理部４によって使い続けられる。そのため、ファイルシステム６はそれらのファイルに関する情報は維持しつづける。
【０１０８】
次に、ＡＢＯＲＴの処理手順について説明する。
【０１０９】
図１９に、ＡＢＯＲＴ（ｔｘｉｄ）の処理手順の一例を示す。
【０１１０】
ＡＢＯＲＴの処理時には、すべてのエントリに対して図１９の手順で処理を行う。
【０１１１】
まず、そのエントリのＴＸＳＴＡＴＥ属性の値を調べる（ステップＳ１１１）。
【０１１２】
ＴＸＳＴＡＴＥ属性を持たない場合は、どのトランザクションもアクセスしていないので何もしなくて良い。
【０１１３】
ＴＸＳＴＡＴＥ属性が「ＲＥＡＤ」の場合は、そのＴＸＩＤ属性の中にｔｘｉｄが含まれていて（ステップＳ１１２）、ｔｘｉｄ以外のトランザクション識別子も含まれていれば（ステップＳ１１３）、ｔｘｉｄを抜く（ステップＳ１０４）。ＴＸＩＤ属性がｔｘｉｄのみをもっている場合には（ステップＳ１１３）、ＴＸＩＤ属性とＴＸＳＴＡＴＥ属性を削除する（ステップＳ１１５）。
【０１１４】
ＴＸＳＴＡＴＥ属性の値が「ＵＰＤＡＴＥ」の場合は、そのＴＸＩＤ属性の値がｔｘｉｄと同じであれば（ステップＳ１１６）、そのエントリのＵＰＤＡＴＥを取り消す操作を行う。このとき、そのエントリに＜ｏｌｄｖａｌｕｅ＞部があれば（ステップＳ１１７）、現在の＜ｖａｌｕｅ＞部を削除して＜ｏｌｄｖａｌｕｅ＞部のタグ名を＜ｖａｌｕｅ＞に戻すことで更新前の値に戻すとともに、ＴＸＩＤ属性とＴＸＳＴＡＴＥ属性を削除する（ステップＳ１１８）。そのエントリに＜ｏｌｄｖａｌｕｅ＞部が無い場合は（ステップＳ１１７）、このトランザクションで新しく作成したエントリであるので、エントリを削除する（ステップＳ１１９）。
【０１１５】
ＴＸＳＴＡＴＥ属性がＲＥＭＯＶＥの場合は（ステップＳ１１１）、そのＴＸＩＤ属性の値がｔｘｉｄと同じであれば（ステップＳ１２０）、ＴＸＩＤ属性とＴＸＳＴＡＴＥ属性を削除して、ＲＥＭＯＶＥを取り消す（ステップＳ１２１）。
【０１１６】
ところで、ＡＢＯＲＴの場合、アボートするトランザクションによるファイルの更新を、バッファ領域６２上で取り消す。このとき、同じファイルを更新していて既にコミットした他のトランザクションがあった場合には、アボートするトランザクションによる更新中の状態もファイルに書きこまれてしまっている可能性がある。しかし、ＡＢＯＲＴ処理時にバッファ領域６２上で取り消した結果のファイルをハードディスク１０に書き込むことは、必ずしも必要無い。なぜなら、次に同じファイルを他のトランザクションが更新してコミットすれば、アボートしたトランザクションによる更新の取り消しはハードディスク１０上に正しく反映される。また、たとえ次にどのトランザクションも更新せずに、そのまま計算機の障害等で忘れ去られてしまった場合でも、後で述べるリカバリ処理によって、次にそのファイルをオープンする時に、ハードディスク１０上のファイルに残っているコミットしていないトランザクションによる更新途中の状態は取り消される。
【０１１７】
次に、リカバリの処理手順について説明する。
【０１１８】
本実施形態のトランザクション処理システムでは、コミットしていないトランザクションによって更新途中のファイルの状態がハードディスク１０に書き戻される。そのため、障害で計算機がダウンした場合には、更新途中の状態が残るので、リカバリ処理を行って更新途中で残された変更を取り消さなくてはいけない。従来のトランザクション処理方式では、このようなリカバリ処理は障害が起こって再起動した直後にまとめて行わなければならない。そのため、障害直後の再起動のオーバヘッドは大きい。しかし、本実施形態のトランザクション処理方式では、リカバリ処理は、次にそのファイルをハードディスク１０から読み出す時点で良い。
【０１１９】
図２０に、リカバリの処理手順の一例を示す。
【０１２０】
共有データ管理部４がまだバッファ領域６２にないファイルを参照するためにオープン処理をファイルシステム６に指示すると、ファイルシステム６はそのファイルをハードディスク１０から読み出してバッファ領域６２にコピーする。その時点で共有データ管理部４は、すべてのエントリに対して図２０に示す手順でリカバリ処理を実行する。
【０１２１】
まず、そのエントリのＴＸＳＴＡＴＥ属性を調べる（ステップＳ２０１）。
【０１２２】
ＴＸＳＴＡＴＥ属性を持たない場合は、どのトランザクションもアクセスしていないので何もしなくて良い。
【０１２３】
ＴＸＳＴＡＴＥ属性の値が「ＲＥＡＤ」の場合は、ＴＸＩＤ属性とＴＸＳＴＡＴＥ属性を削除するだけで良い（ステップＳ２０２）。
【０１２４】
ＴＸＳＴＡＴＥ属性の値が「ＵＰＤＡＴＥ」の場合は、いずれかのトランザクションが更新している途中で障害が発生したことを示しているので、それらをアボートする。このときの動作は、そのエントリに＜ｏｌｄｖａｌｕｅ＞部があるかどうかで異なる。＜ｏｌｄｖａｌｕｅ＞部があれば（ステップＳ２０３）、そのトランザクションの開始以前から存在していたエントリであるので、まず現在の＜ｖａｌｕｅ＞部を削除し、＜ｏｌｄｖａｌｕｅ＞部のタグ名を＜ｖａｌｕｅ＞に変更して値を元に戻し、さらにＴＸＩＤ属性とＴＸＳＴＡＴＥ属性を削除する（ステップＳ２０４）。＜ｏｌｄｖａｌｕｅ＞部が無い場合は（ステップＳ２０３）、このトランザクションが作成したエントリであるので、エントリ全体を削除する（ステップＳ２０５）。
【０１２５】
ＴＸＳＴＡＴＥ属性の値が「ＲＥＭＯＶＥ」の場合は（ステップＳ２０１）、ＴＸＩＤ属性とＴＸＳＴＡＴＥ属性を削除するだけでＲＥＭＯＶＥをキャンセルすることが出来る（ステップＳ２０６）。
【０１２６】
ところで、ファイルをディスクから読み出す度にこのようなリカバリ処理を行うのでは、非常にオーバーヘッドが大きい。そこで、ファイルを書き出すときにそのファイルが更新途中の状態を含んでいるかどうかを簡単に識別できる情報を付けておくことで、このオーバヘッドを無くすことが出来る。その方式は、例えば図２１に示すように、ドキュメントのルートのエレメントの属性として、現在いくつのトランザクションがファイルを更新中かを示す情報を持たせる。図２１の例では、ルートである＜ＫＶｔａｂｌｅ＞のＴＸＮＵＭという属性がそれを示しており、現在、トランザクション（１）とトランザクション（２）の２つのトランザクションが更新中であることを示している。こうしておくと、最初にファイルをディスクから読みだして来た時に、そのルートエレメントがＴＸＮＵＭという属性を持っていたら、そのファイル内のすべてのエントリに対して図２０のリカバリ処理を実行する。もしＴＸＮＵＭという属性が無ければ、リカバリ処理は必要無い。
【０１２７】
さて、これまでの説明では、エントリはルートエレントである＜ＫＶｔａｂｌｅ＞の下にフラットに記録していたが、例えば良く知られた二分木のような構造を使って、検索を高速化するように実施することができる。図２２は、そのように実施した場合のファイルのデータの例である。この例では、エントリには＜ｋｅｙ＞と＜ｖａｌｕｅ＞以外に、＜ｌｅｓｓ＞と＜ｇｒｅａｔｅｒ＞というエレメントを持つ。そのエレメントのキーより小さなキーを持つエントリは＜ｌｅｓｓ＞の下に、大きなキーを持つエントリは＜ｇｒｅａｔｅｒ＞の下にくるように、二分木を構成している。この場合も、トランザクションによるＵＰＤＡＴＥやＲＥＭＯＶＥなどの更新はフラットな場合と同様に扱うことが出来る。ただし、エントリの追加や削除によって木の構成を組み換える処理が必要になる。この処理は通常の木構造のノードの追加／削除とまったく同じ処理である。木構造の組み換え時には、ＡＶＬ木のような手法を使ってうまく木がバランスするように組み換えたり、アクセス頻度の多いエントリが木のルートに近い場所に来るように組み換えたりするように実施することもできる。
【０１２８】
また、本発明は、良く知られたＢ−ＴＲＥＥのような管理構造を使って、ファイルを分割して管理するように実施することも出来る。図２３／図２４／図２５／図２６にその例を示す。ここでは、一つのファイルには最大６個のエントリを収容し、それ以上にエントリが増えるとファイルを分割するというような、Ｂ−ＴＲＥＥと同じアルゴリズムでエントリの追加／削除の処理を行うものとする。図２３／図２４／図２５／図２６の例では、ＦＩＬＥ００１がルートになるファイル、ＦＩＬＥ００２，ＦＩＬＥ００３，ＦＩＬＥ００４がその下にあるファイルである。
【０１２９】
図２７に、このように一纏まりの情報を複数のファイルに分割して記録・管理するようにしたトランザクション処理システムの構成例を示す。
【０１３０】
図２７の構成は、図１の構成と比べて、共有データ管理部４が更新グループ表４２を持つ点が異なる。後に説明するように、複数のファイル間で情報を移動してファイル間の構造を変更した場合に、それらのファイルをコミット時に同時にハードディスク１０に書き戻さなければならない。更新グループ表４２は、そのようなコミット時に同時にハードディスク１０に書き戻したりあるいは削除したりする必要のあるファイルのグループを管理するための表である。
【０１３１】
図２８に更新グループ表４２の例を示す。この更新グループ表には、コミット時に同時に書き戻したり削除したりすべきファイルのグループ毎に、そのメンバが記録されている。図２８では、例えば、ＦＩＬＥ００１とＦＩＬＥ００２とＦＩＬＥ００５がグループになっている。
【０１３２】
さて、図２３／図２４／図２５／図２６のＦＩＬＥ００１から始めて「ＳＥＳＡＭＥ」をキーとするエントリを探す手順は、ＦＩＬＥ００１のルートから始める。まずキーを「ＫＩＷＩＦＲＵＩＴ」と比べるとそれよりも大きい。次にキーを＜ｇｒｅａｔｅｒ＞側の「ＲＯＳＥＭＡＲＹ」と比べるとそれよりも大きい。次に＜ｇｒｅａｔｅｒ＞側を見るとＦＩＬＥ００４へのリンクになっている。そこでＦＩＬＥ００４に移って、キーを「ＴＨＹＭＥ」と比べるとそれよりも小さい。そこで＜ｌｅｓｓ＞側を見ると、キーが「ＳＥＳＡＭＥ」のエントリが見つかる。こうしてエントリが見つかれば、あとはそれへの操作はこれまでの実施形態と同様に、ＴＸＩＤ属性とＴＸＳＴＡＴＥ属性をつけて更新の途中状態を回復可能な形式で保存して行く。
【０１３３】
例えば、図２３／図２４／図２５／図２６の状態のデータに対して、トランザクション（１）がキー「ＯＲＡＮＧＥ」のエントリの値を「２５０円」に更新し、さらにキー「ＳＥＳＡＭＥ」のエントリの値を「１５０円」に更新し、それと並行に動いているトランザクション（２）がキー「ＶＯＤＫＡ」のエントリを削除したとする。この状態で図２３／図２４／図２５／図２６のデータは図２９／図３０のような状態になる。ＵＰＤＡＴＥやＲＥＭＯＶＥなどの更新途中の状態の持ち方は、一つのファイルにすべてのエントリを入れる場合と同じであり、更新したエントリにはＴＸＩＤとＴＸＳＴＡＴＥの２つの属性をつけて管理する。
【０１３４】
図２９／図３０の状態で、トランザクション（１）と（２）が順にコミットおよびアボートする場合の動作例を説明する。
【０１３５】
まず、トランザクション（１）のコミット時には、トランザクション（１）によって更新されたエントリはファイルＦＩＬＥ００３とＦＩＬＥ００４にのみ存在している。そこで、ＦＩＬＥ００３とＦＩＬＥ００４に対してコミット処理を行った図３１／図３２の状態のデータを作成し、これをトランザクション（１）による他のファイルの更新と同時にハードディスク１０に書き戻す。このとき、ＦＩＬＥ００４にはトランザクション（２）による更新途中の状態が含まれたまま書き戻すのは、これまでの実施形態と同じである。
【０１３６】
次に、トランザクション（２）のアボート時には、トランザクション（２）によって更新されたエントリはＦＩＬＥ００４にのみ存在している。そこでＦＩＬＥ００４に対してアボート処理を行った図３３の状態を作成して、アボート処理は終了する。アボート処理時にはファイルのハードディスク１０への書き戻しは必要無いのは、これまでの実施形態と同じである。
【０１３７】
さて、この状態で、新しくトランザクション（３）がキー「ＤＯＤＯ」とキー「ＨＯＯＰＯＥ」のエントリを追加し、それぞれの値を「５００００００円」と「９８００００円」にした後のデータの状態を、図３４／図３５／図３６に示す。ここでは、一つのファイルに入れることの出来るエントリの数は決まっているので、この更新例のように一つのファイルにその容量以上のエントリを追加しようとした場合には、ファイル間で組み換えが発生してエントリが移動する。図３４／図３５／図３６の例では、キー「ＤＯＤＯ」とキー「ＨＯＯＰＯＥ」の二つのエントリを追加しようとしたところ、それらはどちらもＦＩＬＥ００２への追加となる。その結果ＦＩＬＥ００２の分割が行われて、新たにＦＩＬＥ００５が作られてエントリが移動している。
【０１３８】
このようにファイル間でエントリ情報の移動が発生したり、新しいファイルが追加されたり、あるいは逆にファイルが削除されたりすると、それらのファイルの更新は同時にハードディスク１０へ反映させなければならない。そのために、本実施形態のトランザクション処理システムの共有データ管理部４は、更新グループ表４２を管理している。図３４／図３５／図３６の例のように、ＦＩＬＥ００２へのエントリの追加によってＦＩＬＥ００２の分割が発生し、ＦＩＬＥ００１の更新とＦＩＬＥ００５の作成が発生した場合、共有データ管理部４は更新グループ表４２にＦＩＬＥ００１とＦＩＬＥ００２とＦＩＬＥ００５をひとつのグループとして登録する。
【０１３９】
トランザクション（３）のコミットを行う場合、トランザクション（３）が更新したエントリはＦＩＬＥ００１とＦＩＬＥ００５のみに存在するが、更新グループ表４２を参照することで、ＦＩＬＥ００２も同時に書き戻さなければならないことがわかる。そこで、図３７／図３８に示すようにコミット処理を行ったＦＩＬＥ００１とＦＩＬＥ００５に加えてＦＩＬＥ００２の３つのファイルをハードディスク１０に書き戻す。
【０１４０】
このように複数のファイルに分割してデータを持つように本発明を実施する場合には、様々な基準で一つのファイルに入れられるエントリの数を制限することが出来る。そのような基準としては、図３４／図３５／図３６の例のように一つのファイル内のエントリの数で制限する方式、ファイルの物理的なサイズで制限する方式、追加削除の頻度等の情報によって最大のエントリ数を変更する方式、それらの組み合わせなど、様々な方式が考えられる。
【０１４１】
本実施形態のように複数のファイルに分割してデータを記憶する方式は、エントリの数が大きくなったときでも、その一部分しか更新していないなら、コミット時にディスクに書き出すデータ量を減らせるという効果がある。すべてのエントリを一つのファイルに入れる方式では、大きなファイルの一部しか変更していない場合でも、コミット時にファイル全体をディスクに書き戻す必要がある。
【０１４２】
さて、これまでは、キーと値とのペアというデータベース的な構造を持つデータに対して本発明を適用する場合を例とって説明してきた。以下では、他の例として、より一般的なＸＭＬドキュメントに対して本発明を適用する場合について説明する。
【０１４３】
図３９は、一般的なＸＭＬのドキュメントの例である。このドキュメントに対して、トランザクション（１）が「＜ｔｉｔｌｅ＞名古屋＜／ｔｉｔｌｅ＞」の＜ｃｈａｐｔｅｒ＞の＜ａｕｔｈｏｒ＞を「味噌かつ」に変更し、トランザクション（２）が「＜ｃｈａｐｔｅｒ＞＜ｔｉｔｌｅ＞博多＜／ｔｉｔｌｅ＞＜ａｕｔｈｏｒ＞からし明太子＜／ａｕｔｈｏｒ＞＜／ｃｈａｐｔｅｒ＞」を追加した状態のデータが図４０である。
【０１４４】
この後、トランザクション（１）のコミット時にデータを図４１の状態に更新し、これをディスクに書き戻す。
【０１４５】
さらに、トランザクション（２）のコミット時にはデータを図４２の状態に更新し、これをディスクに書き戻す。
【０１４６】
この一般的なＸＭＬドキュメントを対象にした実施形態でも、障害発生によって更新途中で残されたファイルは、次にディスクから読み出した時にチェックし、ＴＸＳＴＡＴＥがＡＤＤのエレメントは削除してＴＸＳＴＡＴＥがＲＥＭＯＶＥのエレメントは残すようなリカバリ処理を行うことで、コミットしていないトランザクションによる一時的な更新を取り消すことが出来る。
【０１４７】
本実施形態によれば、並行に動作する複数のトランザクションによるファイルの更新を、簡単な処理手順で実現することができる。本実施形態によれば、従来のＷＡＬ方式や、シャドウページ方式の上に特殊なログ管理を実装するときのように、データの更新時やコミット処理時あるいはリカバリ時に複雑な処理を必要としない。
【０１４８】
また、本実施形態では、障害発生後のリカバリ処理を、再起動時に集中して行う必要は無く、障害で更新途中の状態は次にそのファイルを使う時点で行われるため、リカバリ処理のオーバヘッドが小さい。
【０１４９】
さらに、本実施形態では、１つのデータを複数のファイルに分けて管理することで、ファイルの更新のコミット時にディスクに書き戻すデータの量を減らすことができる。
【０１５０】
なお、以上の各機能は、ソフトウェアとしても実現可能である。
【０１５１】
また、本実施形態は、コンピュータに所定の手段を実行させるための（あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるための）プログラムを記録したコンピュータ読取り可能な記録媒体としても実施することもできる。
【０１５２】
本発明は、上述した実施の形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。
【０１５３】
【発明の効果】
本発明によれば、並行に動作する複数のトランザクションによるファイルの更新処理と障害時のリカバリ処理を簡単に効率良く実現することができる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るトランザクション処理システムの構成例を示す図
【図２】更新管理表の一例を示す図
【図３】トランザクション管理表の一例を示す図
【図４】ＸＭＬドキュメント（データファイル）の一例を示す図
【図５】ＵＰＤＡＴＥ（１，ＩＣＥＣＲＥＡＭ，４５０円）の処理直後のデータの一例を示す図
【図６】ＵＰＤＡＴＥ（３，ＡＰＰＬＥ，５００円）の処理直後のデータの一例を示す図
【図７】ＲＥＭＯＶＥ（２，ＢＩＳＣＵＩＴ）の処理直後のデータの一例を示す図
【図８】ＵＰＤＡＴＥ（２，ＣＨＯＣＯＬＡＴＥ，３００円）の処理直後のデータの一例を示す図
【図９】ＲＥＭＯＶＥ（１，ＧＲＡＰＥ）の処理直後のデータの一例を示す図
【図１０】ＵＰＤＡＴＥ（２，ＫＩＷＩＦＲＵＩＴ，３００円）の処理直後のデータの一例を示す図
【図１１】ＣＯＭＭＩＴ（３）の処理直後のデータの一例を示す図
【図１２】ＣＯＭＭＩＴ（１）の処理直後のデータの一例を示す図
【図１３】ＡＢＯＲＴ（２）の処理直後のデータの一例を示す図
【図１４】ＲＥＡＤ（ｔｘｉｄ，ｋｅｙ）の処理手順の一例を示すフローチャート
【図１５】ＲＥＡＤ（４，ＣＨＯＣＯＬＡＴＥ）の処理直後のデータの一例を示す図
【図１６】ＵＰＤＡＴＥ（ｔｘｉｄ，ｋｅｙ，ｖａｌｕｅ）の処理手順の一例を示すフローチャート
【図１７】ＲＥＭＯＶＥ（ｔｘｉｄ，ｋｅｙ）の処理手順の一例を示すフローチャート
【図１８】ＣＯＭＭＩＴ（ｔｘｉｄ）の処理手順の一例を示すフローチャート
【図１９】ＡＢＯＲＴ（ｔｘｉｄ）の処理手順の一例を示すフローチャート
【図２０】リカバリの処理手順の一例を示すフローチャート
【図２１】トランザクションによる更新中情報を持つデータの一例を示す図
【図２２】二分木構造により検索を高速化するデータの一例を示す図
【図２３】複数ファイルに分割したデータ管理方式の一例を示す図
【図２４】複数ファイルに分割したデータ管理方式の一例を示す図
【図２５】複数ファイルに分割したデータ管理方式の一例を示す図
【図２６】複数ファイルに分割したデータ管理方式の一例を示す図
【図２７】本発明の一実施形態に係るトランザクション処理システムの他の構成例を示す図
【図２８】更新グループ表の一例を示す図
【図２９】トランザクション（１）と（２）による更新の例を示す図
【図３０】トランザクション（１）と（２）による更新の例を示す図
【図３１】トランザクション（１）のコミット処理の例を示す図
【図３２】トランザクション（１）のコミット処理の例を示す図
【図３３】トランザクション（２）のアボート処理の例を示す図
【図３４】トランザクション（３）による更新の例を示す図
【図３５】トランザクション（３）による更新の例を示す図
【図３６】トランザクション（３）による更新の例を示す図
【図３７】トランザクション（３）のコミット処理の例を示す図
【図３８】トランザクション（３）のコミット処理の例を示す図
【図３９】一般的なＸＭＬドキュメントの例を示す図
【図４０】トランザクション（１）と（２）によるデータの更新例を示す図
【図４１】トランザクション（１）コミット後のデータの一例を示す図
【図４２】トランザクション（２）コミット後のデータの一例を示す図
【図４３】従来のトランザクション処理システムの例を示す図
【符号の説明】
２…アプリケーションプログラム
４…共有データ管理部
４１…更新管理表
４２…更新グループ表
６…ファイルシステム
６１…トランザクション管理表
６２…バッファ領域
８…トランザクションマネージャ
１０…ハードディスク
Claims (4)
- 各トランザクションがそれぞれ１以上のファイルを更新対象とするトランザクション処理システムのトランザクション処理方法であって、
複数のトランザクションが同時に更新対象としているファイルの各々について、当該ファイルのファイル識別情報と当該ファイルを同時に更新対象としている複数のトランザクションのトランザクション識別情報との対応を記録した第１の管理表を記憶する第１のステップと、
一つのトランザクションが占有して更新対象としているファイルの各々について、当該ファイルのファイル識別情報と当該ファイルを更新対象としている一つのトランザクションのトランザクション識別情報との対応を記録した第２の管理表を記憶する第２のステップと、
複数のトランザクションが同時に更新対象としているファイルごとに、それぞれ、安定記憶装置からバッファ領域上に読み出した同一のファイルを更新対象として複数のトランザクションが処理を行う第３のステップと、
前記複数のトランザクションのうちの一つのトランザクションのコミット時に、当該一つのトランザクションのトランザクション識別情報に基づき前記第１の管理表を参照して、当該一つのトランザクションが同時に更新対象としているファイルのファイル識別情報を求め、求めたファイル識別情報に係るファイルそれぞれについて、当該一つのコミットするトランザクションによる確定した更新内容と、他のコミットしていないトランザクションによる未確定の更新内容と、該未確定の更新を取り消すための情報とをファイル内容として含む前記ファイルを、安定記憶装置に書き込むことを、同期して行う第４のステップとを有し、
前記第４のステップにおいては、更に、前記一つのトランザクションのトランザクション識別情報に基づき前記第２の管理表を参照し、当該一つのトランザクションが前記ファイルとは別のファイルを占有して更新対象として前記バッファ領域上で処理を行っていた場合には、前記ファイルの前記安定記憶装置への書き込みと同期させて、当該一つのトランザクションによる前記別のファイルに対する確定した更新内容をファイル内容として含む前記別のファイルを前記安定記憶装置に書き込むことを特徴とするトランザクション処理方法。 - 前記他のコミットしていないトランザクションをコミットする時には、該他のこれからコミットするトランザクションによる新たに確定した更新内容と、以前にコミットしたトランザクションによる既に確定している更新内容のうち該他のこれからコミットするトランザクションによる新たに確定した更新内容とは競合しないものとをファイル内容として含むファイルを、前記安定記憶装置に格納された前記ファイルに上書きすることを特徴とする請求項１に記載のトランザクション処理方法。
- 新しくファイルを前記安定記憶装置から読み出した時に、このファイルに、コミットしていないトランザクションによる未確定の更新内容および該未確定の更新を取り消すための情報が含まれているか否かを調べ、
含まれている場合には、読み出した前記ファイルを前記情報を用いて前記コミットしていないトランザクションによる更新がなかった状態に戻すことを特徴とする請求項１または２に記載のトランザクション処理方法。 - 各トランザクションがそれぞれ１以上のファイルを更新対象とするトランザクション処理システムであって、
複数のトランザクションが同時に更新対象としているファイルの各々について、当該ファイルのファイル識別情報と当該ファイルを同時に更新対象としている複数のトランザクションのトランザクション識別情報との対応を記録した第１の管理表を記憶する手段と、
一つのトランザクションが占有して更新対象としているファイルの各々について、当該ファイルのファイル識別情報と当該ファイルを更新対象としている一つのトランザクションのトランザクション識別情報との対応を記録した第２の管理表を記憶する手段と、
複数のトランザクションが同時に更新対象としているファイルを、それぞれ、安定記憶装置からバッファ領域上に読み出す手段と、
複数のトランザクションが同時に更新対象としているファイルごとに、それぞれ、当該ファイルに対して複数のトランザクションのそれぞれが行った更新の内容と該更新を取り消すための情報とを前記バッファ領域上で該ファイル内に書き込む手段と、
前記複数のトランザクションのうちの一つのトランザクションのコミット時に、当該一つのトランザクションのトランザクション識別情報に基づき前記第１の管理表を参照して、当該一つのトランザクションが同時に更新対象としているファイルのファイル識別情報を求め、求めたファイル識別情報に係るファイルそれぞれについて、当該ファイル内に書き込まれた該一つのコミットするトランザクションによる更新の内容については該更新を取り消すための情報を削除することにより確定させ、前記ファイル内に書き込まれた他のコミットしていないトランザクションによる更新の内容および該更新を取り消すための情報についてはそのままとし、確定させた内容とそのままとした情報とをファイル内容として含む前記ファイルを、前記安定記憶装置に書き出すことを、同期して行う制御手段とを備え、
前記制御手段は、更に、前記一つのトランザクションのトランザクション識別情報に基づき前記第２の管理表を参照し、当該一つのトランザクションが前記ファイルとは別のファイルを占有して更新対象として前記バッファ領域上で処理を行っていた場合には、前記ファイルの前記安定記憶装置への書き込みと同期させて、当該一つのトランザクションによる前記別のファイルに対する確定した更新内容をファイル内容として含む前記別のファイルを前記安定記憶装置に書き込むことを特徴とするトランザクション処理システム。
Priority Applications (6)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP27626499A JP4237354B2 (ja) | 1999-09-29 | 1999-09-29 | トランザクション処理方法及びトランザクション処理システム |
| US09/660,461 US6519614B1 (en) | 1999-09-29 | 2000-09-12 | Transaction processing system using efficient file update processing and recovery processing |
| EP00307894.6A EP1089177B1 (en) | 1999-09-29 | 2000-09-13 | Transaction processing system using efficient file update processing and recovery processing |
| TW089118907A TW550474B (en) | 1999-09-29 | 2000-09-15 | Transaction processing system applying with efficient file updating and recovery processes |
| KR10-2000-0056689A KR100398753B1 (ko) | 1999-09-29 | 2000-09-27 | 효과적인 파일 갱신 처리 및 복구 처리를 이용하는트랜잭션 처리 시스템 |
| US10/307,974 US6834275B2 (en) | 1999-09-29 | 2002-12-03 | Transaction processing system using efficient file update processing and recovery processing |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP27626499A JP4237354B2 (ja) | 1999-09-29 | 1999-09-29 | トランザクション処理方法及びトランザクション処理システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001101045A JP2001101045A (ja) | 2001-04-13 |
| JP4237354B2 true JP4237354B2 (ja) | 2009-03-11 |
Family
ID=17567023
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP27626499A Expired - Lifetime JP4237354B2 (ja) | 1999-09-29 | 1999-09-29 | トランザクション処理方法及びトランザクション処理システム |
Country Status (5)
| Country | Link |
|---|---|
| US (2) | US6519614B1 (ja) |
| EP (1) | EP1089177B1 (ja) |
| JP (1) | JP4237354B2 (ja) |
| KR (1) | KR100398753B1 (ja) |
| TW (1) | TW550474B (ja) |
Families Citing this family (39)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4237354B2 (ja) * | 1999-09-29 | 2009-03-11 | 株式会社東芝 | トランザクション処理方法及びトランザクション処理システム |
| US7512635B1 (en) * | 2000-12-18 | 2009-03-31 | Bmc Software, Inc. | System and method for updating information on a computer system using a limited amount of space |
| US7555500B2 (en) * | 2001-02-15 | 2009-06-30 | Teradata Us, Inc. | Optimized end transaction processing |
| KR100625595B1 (ko) * | 2001-05-28 | 2006-09-20 | 한국전자통신연구원 | 트랜잭션 처리 시스템의 병렬 로깅 방법 및 트랜잭션 로그 처리 시스템 |
| US6857053B2 (en) * | 2002-04-10 | 2005-02-15 | International Business Machines Corporation | Method, system, and program for backing up objects by creating groups of objects |
| US7430740B1 (en) * | 2002-04-12 | 2008-09-30 | 724 Solutions Software, Inc | Process group resource manager |
| US7076508B2 (en) * | 2002-08-12 | 2006-07-11 | International Business Machines Corporation | Method, system, and program for merging log entries from multiple recovery log files |
| US7424671B2 (en) | 2003-05-16 | 2008-09-09 | Justsystems Canada Inc. | Methods and systems for enabling collaborative authoring of hierarchical documents |
| US7243088B2 (en) * | 2003-08-06 | 2007-07-10 | Oracle International Corporation | Database management system with efficient version control |
| US7490113B2 (en) * | 2003-08-27 | 2009-02-10 | International Business Machines Corporation | Database log capture that publishes transactions to multiple targets to handle unavailable targets by separating the publishing of subscriptions and subsequently recombining the publishing |
| US7269588B1 (en) | 2003-09-24 | 2007-09-11 | Oracle International Corporation | Neighborhood locking technique for increasing concurrency among transactions |
| US7555481B1 (en) | 2003-10-28 | 2009-06-30 | Oracle Corporation | Method and apparatus for increasing transaction concurrency by early release of locks in groups |
| US7730489B1 (en) * | 2003-12-10 | 2010-06-01 | Oracle America, Inc. | Horizontally scalable and reliable distributed transaction management in a clustered application server environment |
| US7739244B2 (en) * | 2004-10-14 | 2010-06-15 | Oracle International Corporation | Operating logging for online recovery in shared memory information systems |
| JP2006163596A (ja) * | 2004-12-03 | 2006-06-22 | Internatl Business Mach Corp <Ibm> | 情報処理システム、制御方法、及びプログラム |
| US7539694B1 (en) | 2005-02-04 | 2009-05-26 | Marvell International Ltd. | Concurrently searching and manipulating binary trees |
| GB0506059D0 (en) * | 2005-03-24 | 2005-05-04 | Ibm | Methods and apparatus for switching between data streams |
| US20060265485A1 (en) * | 2005-05-17 | 2006-11-23 | Chai Sek M | Method and apparatus for controlling data transfer in a processing system |
| JP4571090B2 (ja) * | 2006-03-28 | 2010-10-27 | 株式会社野村総合研究所 | スケジューラプログラム、サーバシステム、スケジューラ装置 |
| US8112396B2 (en) * | 2006-06-07 | 2012-02-07 | Emc Corporation | Backup and recovery of integrated linked databases |
| US7860847B2 (en) * | 2006-11-17 | 2010-12-28 | Microsoft Corporation | Exception ordering in contention management to support speculative sequential semantics |
| US8024714B2 (en) | 2006-11-17 | 2011-09-20 | Microsoft Corporation | Parallelizing sequential frameworks using transactions |
| US8010550B2 (en) * | 2006-11-17 | 2011-08-30 | Microsoft Corporation | Parallelizing sequential frameworks using transactions |
| JP4942519B2 (ja) * | 2007-03-14 | 2012-05-30 | 株式会社日立製作所 | 情報処理装置、プログラム及び情報処理方法 |
| US20080319878A1 (en) * | 2007-06-22 | 2008-12-25 | Thorsten Glebe | Dynamic Time Series Update Method |
| US20090193410A1 (en) * | 2007-09-28 | 2009-07-30 | Xcerion Aktiebolag | Network operating system |
| KR101583716B1 (ko) | 2009-01-30 | 2016-01-08 | 삼성전자주식회사 | 비트 로깅을 이용한 데이터 복구 방법 및 그 장치 |
| US9325802B2 (en) * | 2009-07-16 | 2016-04-26 | Microsoft Technology Licensing, Llc | Hierarchical scale unit values for storing instances of data among nodes of a distributed store |
| KR101587995B1 (ko) * | 2009-10-28 | 2016-01-22 | 삼성전자주식회사 | 적응적 로깅 장치 및 방법 |
| JP5427593B2 (ja) * | 2009-12-25 | 2014-02-26 | 富士通フロンテック株式会社 | 情報処理装置、情報処理方法、および情報処理プログラム |
| US20120222051A1 (en) * | 2011-02-25 | 2012-08-30 | Microsoft Corporation | Shared resource access verification |
| CN102131002B (zh) * | 2011-03-29 | 2016-10-05 | 华为终端有限公司 | 一种手机数据处理方法和装置 |
| US20150286671A1 (en) * | 2012-10-29 | 2015-10-08 | Nec Corporation | Transaction system |
| US20160275089A1 (en) * | 2015-03-17 | 2016-09-22 | Netapp, Inc. | Methods for implementing nosql database snapshots and devices thereof |
| US20200092160A1 (en) * | 2018-09-18 | 2020-03-19 | Electronics And Telecommunications Research Institute | Fault event management method for controller-based restoration |
| EP4133379B1 (en) * | 2020-04-08 | 2023-12-27 | nCipher Security Limited | A device, a method of performing a file transaction, and a method of performing an access operation |
| KR102472878B1 (ko) * | 2020-11-27 | 2022-12-01 | 이화여자대학교 산학협력단 | 가상 머신 환경에서의 블록 커밋 방법 및 그 방법을 수행하는 가상화 시스템 |
| KR102644923B1 (ko) | 2020-12-01 | 2024-03-08 | 김동현 | 롤타입 방충망이 구비된 창틀 |
| JP2023037883A (ja) * | 2021-09-06 | 2023-03-16 | キオクシア株式会社 | 情報処理装置 |
Family Cites Families (30)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4791556A (en) * | 1984-08-29 | 1988-12-13 | Vilkaitis John V | Method for operating a computer which searches for operational symbols and executes functions corresponding to the operational symbols in response to user inputted signal |
| US4945474A (en) * | 1988-04-08 | 1990-07-31 | Internatinal Business Machines Corporation | Method for restoring a database after I/O error employing write-ahead logging protocols |
| DE68927705T2 (de) * | 1989-06-13 | 1997-07-17 | Ibm | Verfahren zum Entfernen unbestätigter Änderungen an gespeicherten Daten durch ein Datenbankverwaltungssystem |
| US5247672A (en) * | 1990-02-15 | 1993-09-21 | International Business Machines Corporation | Transaction processing system and method with reduced locking |
| US5201044A (en) * | 1990-04-16 | 1993-04-06 | International Business Machines Corporation | Data processing method for file status recovery includes providing a log file of atomic transactions that may span both volatile and non volatile memory |
| US5319773A (en) * | 1990-05-16 | 1994-06-07 | International Business Machines Corporation | Asynchronous resynchronization of a commit procedure |
| DE69119222T2 (de) * | 1991-06-04 | 1996-11-21 | Ibm | Datensicherung und Beseitigung in einem Datenverarbeitungssystem |
| US5504899A (en) * | 1991-10-17 | 1996-04-02 | Digital Equipment Corporation | Guaranteeing global serializability by applying commitment ordering selectively to global transactions |
| JPH05233570A (ja) * | 1991-12-26 | 1993-09-10 | Internatl Business Mach Corp <Ibm> | 異オペレーティング・システム間分散データ処理システム |
| US5522066A (en) * | 1992-04-16 | 1996-05-28 | Industrial Technology Research Institute | Interface for accessing multiple records stored in different file system formats |
| US5452445A (en) * | 1992-04-30 | 1995-09-19 | Oracle Corporation | Two-pass multi-version read consistency |
| US5530848A (en) * | 1992-10-15 | 1996-06-25 | The Dow Chemical Company | System and method for implementing an interface between an external process and transaction processing system |
| GB2273180A (en) * | 1992-12-02 | 1994-06-08 | Ibm | Database backup and recovery. |
| US5504883A (en) * | 1993-02-01 | 1996-04-02 | Lsc, Inc. | Method and apparatus for insuring recovery of file control information for secondary storage systems |
| JPH06266597A (ja) * | 1993-03-11 | 1994-09-22 | Fujitsu Ltd | ログ取得方式 |
| JP2557192B2 (ja) * | 1993-03-15 | 1996-11-27 | インターナショナル・ビジネス・マシーンズ・コーポレイション | トランザクション処理の同期方法、トランザクション処理のモニタ方法及びトランザクションのコミット処理方法 |
| US5455944A (en) * | 1993-03-16 | 1995-10-03 | International Business Machines Corporation | Method for managing logging and locking of page free space information in a transaction processing system |
| GB2281644A (en) * | 1993-09-02 | 1995-03-08 | Ibm | Fault tolerant transaction-oriented data processing. |
| US5553279A (en) * | 1993-10-08 | 1996-09-03 | International Business Machines Corporation | Lossless distribution of time series data in a relational data base network |
| US5561795A (en) * | 1994-05-13 | 1996-10-01 | Unisys Corporation | Method and apparatus for audit trail logging and data base recovery |
| US5586312A (en) * | 1994-10-11 | 1996-12-17 | Unisys Corporation | Method and apparatus for using an independent transaction processing application as a service routine |
| US5680610A (en) * | 1995-01-19 | 1997-10-21 | Unisys Corporation | Method and apparatus for testing recovery scenarios in global transaction processing systems |
| WO1996027157A1 (fr) * | 1995-02-28 | 1996-09-06 | Ntt Data Communications Systems Corporation | Systeme associatif decentralise et traitements de journaux et de reprise dans celui-ci |
| US5712971A (en) * | 1995-12-11 | 1998-01-27 | Ab Initio Software Corporation | Methods and systems for reconstructing the state of a computation |
| US5850507A (en) * | 1996-03-19 | 1998-12-15 | Oracle Corporation | Method and apparatus for improved transaction recovery |
| US5857204A (en) * | 1996-07-02 | 1999-01-05 | Ab Initio Software Corporation | Restoring the state of a set of files |
| US5781910A (en) * | 1996-09-13 | 1998-07-14 | Stratus Computer, Inc. | Preforming concurrent transactions in a replicated database environment |
| US6035379A (en) * | 1997-01-09 | 2000-03-07 | Microsoft Corporation | Transaction processing for user data employing both logging and shadow copying |
| US6275863B1 (en) * | 1999-01-25 | 2001-08-14 | International Business Machines Corp. | System and method for programming and executing long running transactions |
| JP4237354B2 (ja) * | 1999-09-29 | 2009-03-11 | 株式会社東芝 | トランザクション処理方法及びトランザクション処理システム |
-
1999
- 1999-09-29 JP JP27626499A patent/JP4237354B2/ja not_active Expired - Lifetime
-
2000
- 2000-09-12 US US09/660,461 patent/US6519614B1/en not_active Expired - Lifetime
- 2000-09-13 EP EP00307894.6A patent/EP1089177B1/en not_active Expired - Lifetime
- 2000-09-15 TW TW089118907A patent/TW550474B/zh not_active IP Right Cessation
- 2000-09-27 KR KR10-2000-0056689A patent/KR100398753B1/ko not_active IP Right Cessation
-
2002
- 2002-12-03 US US10/307,974 patent/US6834275B2/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| KR100398753B1 (ko) | 2003-09-19 |
| JP2001101045A (ja) | 2001-04-13 |
| US6519614B1 (en) | 2003-02-11 |
| US20030078910A1 (en) | 2003-04-24 |
| EP1089177B1 (en) | 2014-04-30 |
| EP1089177A2 (en) | 2001-04-04 |
| KR20010050667A (ko) | 2001-06-15 |
| EP1089177A3 (en) | 2003-05-02 |
| US6834275B2 (en) | 2004-12-21 |
| TW550474B (en) | 2003-09-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4237354B2 (ja) | トランザクション処理方法及びトランザクション処理システム | |
| US11775499B2 (en) | Update and query of a large collection of files that represent a single dataset stored on a blob store | |
| US11061928B2 (en) | Snapshots and forks of storage systems using distributed consistent databases implemented within an object store | |
| US11132350B2 (en) | Replicable differential store data structure | |
| US8510336B2 (en) | Transactional file system | |
| EP2356560B1 (en) | Atomic multiple modification of data in a distributed storage system | |
| EP2452261B1 (en) | Apparatus and method for read optimized bulk data storage | |
| JPH0212460A (ja) | 索引木への並列アクセスのためのデータ・アクセス方法およびデータ処理システム | |
| JPH06332778A (ja) | トランザクション管理方法 | |
| EP1040433A1 (en) | A fine-grained consistency mechanism for optimistic concurrency control using lock groups | |
| JPH04337850A (ja) | データベース・トランザクション及び照会処理システム | |
| US20050125458A1 (en) | Chronological data record access | |
| JP2006018796A (ja) | データ処理方法および装置並びにストレージ装置およびその処理プログラム | |
| US7051051B1 (en) | Recovering from failed operations in a database system | |
| JP3785004B2 (ja) | トランザクション管理方法及びトランザクション管理装置 | |
| WO2015134680A1 (en) | Snapshots and forks of storage systems using distributed consistent databases implemented within an object store | |
| JPH04191934A (ja) | 機能別プログラム管理方法および装置 | |
| JP2002268930A (ja) | データベース構成変更装置、方法及び記録媒体 | |
| KR20010057884A (ko) | 데이터 저장시스템에서 데이터 버퍼 제어 블록을 이용한로그 우선 출력 프로토콜 수행 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041201 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080313 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080325 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080526 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080819 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081020 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20081216 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20081218 |
|
| R151 | Written notification of patent or utility model registration |
Ref document number: 4237354 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111226 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121226 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121226 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131226 Year of fee payment: 5 |
|
| EXPY | Cancellation because of completion of term |