JP4311059B2 - トランザクション制御方法 - Google Patents
トランザクション制御方法 Download PDFInfo
- Publication number
- JP4311059B2 JP4311059B2 JP2003084092A JP2003084092A JP4311059B2 JP 4311059 B2 JP4311059 B2 JP 4311059B2 JP 2003084092 A JP2003084092 A JP 2003084092A JP 2003084092 A JP2003084092 A JP 2003084092A JP 4311059 B2 JP4311059 B2 JP 4311059B2
- Authority
- JP
- Japan
- Prior art keywords
- resource
- transaction
- resource adapter
- wrapper
- manager
- 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 - Fee Related
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、不揮発性記憶を持たないリソースアダプタが１つのリソースマネジャを共有する分散トランザクションシステムで一相コミットを最適化する方法および装置に関する。
【０００２】
【従来の技術】
多くのデータ処理システムが導入している概念にトランザクションがある。トランザクションとは、データ処理のシーケンスを区切ってデータ処理の排他制御、障害回復などを行う管理単位である。１つのトランザクションは、処理のシーケンスの途中にトランザクション開始命令を発行した時点から、トランザクション終了命令を発行した時点までの処理のシーケンスである。トランザクション内で実行した処理はすべて実行されたか、全く実行されなかったか、のいずれかになることが保証される。これによりデータの整合性の保証が容易となる。
【０００３】
例えば、１つのデータベース内で２つのレコードを更新する場合、トランザクションを開始し、２つのレコードを更新し、トランザクションを終了することで１つのトランザクションとなる。このとき、処理が成功して必ず２つのレコードが両方とも更新されるか、処理が失敗して必ず２つのレコードが両方とも更新されないかの、いずれかであり、１つのレコードが更新され他方のレコードが更新されないということがないことがトランザクションによって保証される。いずれの場合も２つのレコード間の整合性は保証されている。
【０００４】
前記の例を実現するために、データベースはトランザクション中に行われた更新情報を主記憶上のバッファに蓄積し、トランザクション終了命令発行時にその更新情報を二次記憶に一度に書出して確定させる。途中で失敗した場合は更新情報を破棄してすべての更新を破棄し処理されなかったことにする。
【０００５】
前記の例ではデータベースが１個であったが、データベースが複数ある場合はトランザクション処理を行うためにさらに別の処理が必要である。例えば、２つのデータベースのレコードをそれぞれ更新する場合、トランザクションを開始し、データベース１のレコード１を更新し、データベース２のレコード２を更新し、トランザクションを終了することで１つのトランザンクションとするにはトランザクションを調停するトランザクションマネジャを新たに導入し、次のような処理が必要である。各々のデータベースはトランザクション中に行われた更新情報を各々の主記憶上のバッファに蓄積する。
【０００６】
トランザクション終了命令発行時には、トランザクションマネジャが調停を行う。まず、トランザクションマネジャから各々のデータベースに対してデータベースの更新情報を確定も取消しも可能な形で一旦二次記憶に一度に書出すように指示する。この処理をプリペアと呼ぶ。各々のデータベースはプリペアが成功したかどうかをトランザクションマネジャへ応答する。トランザクションマネジャは両方のデータベースのプリペアが成功した場合トランザクションログを二次記憶に書出してトランザクションが、成功したことを確定させる。
【０００７】
次に、トランザクションマネジャから各々のデータベースに対してデータベースの更新を確定させるように指示する。この処理をコミットと呼ぶ。各々のデータベースがコミットを終了したことをトランザクションマネジャへ応答するとトランザクション終了命令の処理は完了する。このようにプリペアとコミットの２段階でトランザクション終了処理を行う手順を二相コミットと呼ぶ。
【０００８】
二相コミット処理では、複数のデータベースの更新処理がすべて成功したか確認するためプリペアが必要であった。しかし、データベースが１個のみ存在する場合は、複数のデータベースについて確認する必要がないため、プリペアを省略して、トランザクションマネジャからデータベースにコミット処理するよう指示可能である。このときのコミット処理を一相コミットと呼び、一相コミットを実施することを一相コミット最適化と呼ぶ。一相コミット最適化を行った場合は、トランザクションマネジャがトランザクションログを二次記憶に書出す必要がなく、性能が向上する。
【０００９】
このような二相コミット処理するためのモデルとして、以下に述べるモデルが広く使われている（例えば、非特許文献１参照）。このモデルでは、前記の例のデータベースを一般化して、リソースマネジャと呼び、前記の例のトランザクションをグローバルトランザクションと呼ぶ。グローバルトランザクションは複数存在するので一意な識別子をつけて区別する。この識別子をグローバルトランザクション識別子と呼ぶ。トランザクションマネジャが二相コミット処理を行う対象は個々のリソースマネジャまたは、リソースマネジャをグループ化した単位で行う。この単位をトランザクションブランチと呼ぶ。トランザクションブランチを区別する識別子をブランチ修飾子と呼ぶ。
【００１０】
このモデルでは、リソースマネジャの処理をトランザクションとして行う場合リソースマネジャとトランザクションブランチを関連付けてから、リソースマネジャの処理を行う。この処理を関連付けと呼ぶ。リソースマネジャの行う一相コミット、プリペア、コミットの処理をまとめて決着と呼ぶ。関連付けはリソースマネジャごとに行われるが、決着はトランザクションブランチごとに行われる。そのため、トランザクションブランチに複数のリソースマネジャが含まれる場合は、トランザクションマネジャはそれらのリソースマネジャから任意の１つを選んで決着を行う。トランザクションに含まれるトランザクションブランチが１個場合は一相コミット最適化が実施される。
【００１１】
【非特許文献１】
X/Open Snapshot Distributed Transaction Processing:The XA+ Specification Version 2、 X/Open Company Ltd.、1994、pp.3.
【００１２】
【発明が解決しようとする課題】
本発明では、不揮発性記憶を持たず、別のリソースマネジャのデータをキャッシュするリソースマネジャをリソースアダプタと呼ぶ。複数のリソースアダプタが単一のリソースマネジャを共有して利用している構成では、実際に二次記憶に更新情報を書出す必要があるのは、単一のリソースマネジャのみであり、トランザクションマネジャのトランザクションログの書出しは不要である。従来の技術では、トランザクションマネジャが直接管理するリソースアダプタが複数存在すると、リソースアダプタの数だけトランザクションブランチが生成されて不要な二相コミット処理が行われるため、トランザクションマネジャのトランザクションログが出力され性能を低下させていた。
【００１３】
本発明の目的はこのような場合に一相コミット最適化を可能にする方法及び装置を提供することにある。
【００１４】
【課題を解決するための手段】
本発明では、以下の手順で本発明の目的を達成する。
【００１５】
同じリソースに属するリソースマネジャをグループ化して管理する。リソースアダプタをリソースアダプタラッパでラップし、前記のグループに属するリソースマネジャを利用するリソースアダプタのリソースアダプタラッパが単一のトランザクションブランチに属するようにグループ化してトランザクションマネジャに登録する。トランザクションブランチが単一になるため一相コミット最適化が実施される。決着はトランザクションブランチに含まれる任意の１個のリソースアダプタに対して行われるので、リソースマネジャグループ管理部のグループ表を参照して決着処理の呼出をグループに属するリソースアダプタへ配布する。これによってリソースマネジャの決着処理が重複して呼出されないようにするため、リソースマネジャの決着処理を呼出すリソースアダプタについては対応するリソースマネジャを決着処理では何も処理しないリソースマネジャラッパでラップする。代わりに、リソースマネジャグループ管理部が決着用リソースマネジャの決着処理を呼出して決着処理が１回だけ呼出されるようにする。
【００１６】
【発明の実施の形態】
本発明の実施形態について図面を用いて説明する。
【００１７】
図１は、本実施例の概要の構成を示した図である。
【００１８】
トランザクションマネジャ１００はグローバルトランザクション識別子ＧＴＲＩＤ１０１項目と、リソースマネジャを識別するＲＡＩＤ１０２項目と、トランザクションブランチ修飾子ＢＱＵＡＬ１０３項目を含み、レコード１０４はＧＴＲＩＤ「Ｔ１」、ＲＡＩＤ「ＲＡＷ１」、ＢＱＵＡＬ「Ｂ１」を格納し、レコード１０５はＧＴＲＩＤ「Ｔ１」、ＲＡＩＤ「ＲＡＷ２」、ＢＱＵＡＬ「Ｂ１」を格納し、レコード１０６はＧＴＲＩＤ「Ｔ１」、ＲＡＩＤ「ＲＡＷ３」、ＢＱＵＡＬ「Ｂ１」を格納する。トランザクションマネジャ１００はリソースアダプタラッパを登録するリソース登録手続き１０７を含む。
【００１９】
リソースアダプタラッパＲＡＷ１（１１０）、ＲＡＷ２（１１５）、ＲＡＷ３（１１７）は関連付け手続き１１１と、決着手続き１１２を含む。関連付け手続き１１１は対応するリソースアダプタの関連付け手続きを呼出す。決着手続き１１２は一相コミット処理、プリペア処理、コミット処理を含み、リソースマネジャグループ管理部１３０の表を参照して、対応するリソースアダプタの決着手続きを適宜呼出す。
【００２０】
リソースマネジャグループ管理部１３０はリソースアダプタラッパを識別するラッパＲＡＩＤ１３１項目と、リソースアダプタの決着処理の呼出が要不要を表す決着１３２項目と、グループを識別するグループ１３３項目を含み、レコード１３４はラッパＲＡＩＤ「ＲＡＷ１」、決着「不要」、グループ「Ｇ１」を格納し、レコード１３５はラッパＲＡＩＤ「ＲＡＷ２」、決着「必要」、グループ「Ｇ１」を格納し、レコード１３６はラッパＲＡＩＤ「ＲＡＷ３」、決着「必要」、グループ「Ｇ１」を格納する。リソースマネジャグループ管理部１３０はリソースマネジャグループを識別するグループ１３７項目と決着用リソースマネジャを識別する決着用ＲＭＩＤ１３８項目を含み、レコード１３９はグループ「Ｇ１」、決着用ＲＭＩＤ「ＲＭ４」を格納する。
【００２１】
リソースアダプタＲＡ１（１４０）は関連付け手続き１４１と、決着手続き１４２と、利用するリソースマネジャを識別する利用ＲＭＩＤ１４３項目を含み、レコード１４４は利用ＲＭＩＤ「ＲＭ１」を格納する。リソースアダプタＲＡ１（１４０）はデータを含まないため、決着手続き１４２を呼出す必要はない。
【００２２】
リソースアダプタＲＡ２（１５０）は関連付け手続き１５１と、決着手続き１５２と、利用するリソースマネジャを識別する利用ＲＭＩＤ１５３項目を含み、レコード１５４は利用ＲＭＩＤ「ＲＭ２」を格納する。リソースアダプタＲＡ２（１５０）は決着手続き１５２によって更新されるデータ１５５を含むため、決着手続き１５２を呼出す必要がある。
【００２３】
リソースアダプタＲＡ３（１６０）は関連付け手続き１６１と、決着手続き１６２と、利用するリソースマネジャを識別する利用ＲＭＩＤ１６３項目を含み、レコード１６４は利用ＲＭＩＤ「ＲＭＷ１」を格納する。リソースアダプタＲＡ３（１６０）は決着手続き１６２によって更新されるデータ１６５を含むため、決着手続き１６２を呼出す必要がある。
【００２４】
リソースマネジャラッパＲＭＷ１（１７０）は関連付け手続き１７１と、決着手続き１７２と、ラップ先リソースマネジャを識別するラップ先ＲＭＩＤ１７３項目を含み、レコード１７４はラップＲＭＩＤ「ＲＭ３」を格納する。
【００２５】
リソースマネジャＲＭ１（１８０）、ＲＭ２（１８５）、ＲＭ３（１８６）、ＲＭ４（１８７）は同一のリソース１９０に属し、関連付け手続き１８１と、決着手続き１８２を含む。
【００２６】
図２は、リソース１９０がデータベースである場合の実施例を示した図である。リソース１９０に属するリソースマネジャＲＭ１（１８０）、ＲＭ２（１８５）、ＲＭ３（１８６）、ＲＭ４（１８７）はデータベースアクセス制御２００を通じて同一のデータベース２１０をアクセスする。データベースアクセス制御２００は、グローバルトランザクションを識別するＧＴＲＩＤ２０１項目と、データベースコネクションを識別するＣＩＤ２０２項目を含み、レコード２０３はＧＴＲＩＤ「Ｔ１」、ＣＩＤ「Ｃ１」を格納する。これにより複数のリソースマネジャが共通のリソースにアクセス可能である。
【００２７】
図３は、装置の構成を示した図である。
【００２８】
計算機３０１は、主記憶装置３１０、二次記憶装置３２０、ＣＰＵ３８０、マウス３８１、ディスプレイ３８２、キーボード３８３、ネットワークインタフェース３８５、及びこれらを相互接続するバス３７０から構成される。そして、計算機３０１はネットワークインタフェース３８５を介して、ネットワーク３９０に接続される。主記憶装置３１０には、オペレーティングシステム３１１、トランザクションマネジャ１００、リソースアダプタラッパＲＡＷ１（１１０）、ＲＡＷ２（１１５）、ＲＡＷ３（１１７）、リソースアダプタグループ管理部１３０、リソースアダプタＲＡ１（１４０）、ＲＡ２（１５０）、ＲＡ３（１６０）、リソースマネジャラッパＲＭＷ１（１７０）、リソース１９０に属するリソースマネジャＲＭ１（１８０）、ＲＭ２（１８５）、ＲＭ３（１８６）、ＲＭ４（１８７）とデータベースアクセス制御２００を記憶している。二次記憶装置３２０には、データベース記憶域を記憶している。
【００２９】
図４から図８を用いて、トランザクション処理の手順の詳細を示す。トランザクションマネジャ１００はトランザクションの開始時にリソース登録手続き１０７を呼出して、リソースアダプタラッパＲＡＷ１（１１０）、ＲＡＷ２（１１５）、ＲＡＷ３（１１７）を登録する。このシーケンスは図４に示されている。トランザクションマネジャ１００はトランザクションの終了時に図５に示す処理を行い、一相コミット最適化または二相コミット処理を行う。本実施例ではトランザクションマネジャ１００が決着処理時にトランザクションブランチに含まれるリソースアダプタラッパＲＡＷ１（１１０）、ＲＡＷ２（１１５）、ＲＡＷ３（１１７）のうちリソースアダプタラッパＲＡＷ１（１１０）を選択したものとして説明する。図６に一相コミット処理でリソースアダプタラッパＲＡＷ１（１１０）が行う処理、図７にプリペア処理でリソースアダプタラッパＲＡＷ１（１１０）が行う処理、図８にコミット処理でリソースアダプタラッパＲＡＷ１（１１０）が行う処理、を示す。
【００３０】
図４は、リソース登録手続き１０７の動作をフローチャートで示した図である。リソース登録手続き１０７は、動作中のグローバルトランザクションを識別するＧＴＲＩＤと登録対象のリソースアダプタを識別するＲＡＩＤを入力とする。
【００３１】
（ステップ４０１）トランザクションマネジャ１００のテーブルに対して探索エントリを先頭に位置付ける。
【００３２】
（ステップ４０２）探索が終了したかを判定する。
【００３３】
（ステップ４０３）リソースアダプタグループ管理部１３０のテーブルのラッパＲＡＩＤ１３１項目とグループ１３３項目を参照して、登録対象のＲＡＩＤに対応するグループと探索エントリのＲＡＩＤ１０２項目に対応するグループを比較する。
【００３４】
（ステップ４０４）新しいトランザクションブランチを生成するために、新しいＢＱＵＡＬを生成して設定ＢＱＵＡＬとする。
【００３５】
（ステップ４０５）比較結果が一致を示すかを判定する。
【００３６】
（ステップ４０６）探索エントリを１つ進める。
【００３７】
（ステップ４０７）現在の探索エントリのＢＱＵＡＬを得て設定ＢＱＵＡＬとする。
【００３８】
（ステップ４０８）ＧＴＲＩＤと登録対象のＲＭＩＤと設定ＢＱＵＡＬをトランザクションマネジャのテーブルに登録する。
【００３９】
図５は、トランザクションマネジャ１００が行うトランザクションコミット処理をフローチャートで示した図である。
【００４０】
（ステップ５０１）コミット対象のトランザクションに含まれるトランザクションブランチ数を数える。
【００４１】
（ステップ５０２）トランザクションブランチ数が１かを判定する。
【００４２】
（ステップ５０３）トランザクションブランチごとに任意のリソースアダプタラッパを選び、すべてプリペアする。本実施例ではリソースアダプタラッパＲＡＷ１（１１０）を選んでプリペアする。
【００４３】
（ステップ５０４）任意のリソースアダプタラッパを選び、一相コミットする。本実施例ではリソースアダプタラッパＲＡＷ１（１１０）を選んで一相コミットする。
【００４４】
（ステップ５０５）すべてプリペア成功応答かを判定する。
【００４５】
（ステップ５０６）トランザクションブランチごとに任意のリソースアダプタラッパを選び、すべてコミット完了する。本実施例ではリソースアダプタラッパＲＡＷ１（１１０）を選んでコミット完了する。
【００４６】
（ステップ５０７）トランザクションブランチごとに任意のリソースアダプタラッパを選び、すべてロールバック完了する。本実施例ではリソースアダプタラッパＲＡＷ１（１１０）を選んでロールバック完了する。
【００４７】
図６は、リソースアダプタラッパＲＡＷ１（１１０）が一相コミットを行う動作をフローチャートで示した図である。
【００４８】
（ステップ６０１）一相コミット指示を受取る。
【００４９】
（ステップ６０２）グループ内で決着必要なリソースアダプタＲＡ２（１５０）、ＲＡ３（１６０）をすべてプリペアする。
【００５０】
（ステップ６０３）すべて成功したかを判定する。
【００５１】
（ステップ６０４）決着用リソースマネジャＲＭ４（１８７）をコミットする。
【００５２】
（ステップ６０５）決着用リソースマネジャＲＭ４（１８７）をロールバックする。
【００５３】
（ステップ６０６）決着用リソースマネジャＲＭ４（１８７）のコミットが成功したかを判定する。
【００５４】
（ステップ６０７）グループ内で決着必要なリソースアダプタＲＡ２（１５０）、ＲＡ３（１６０）をすべてコミットする。
【００５５】
（ステップ６０８）グループ内で決着必要なリソースアダプタＲＡ２（１５０）、ＲＡ３（１６０）をすべてロールバックする。
【００５６】
（ステップ６０９）一相コミット成功応答を返す。
【００５７】
（ステップ６１０）一相コミット失敗応答を返す。
【００５８】
図７は、リソースアダプタラッパＲＡＷ１（１１０）がプリペアを行う動作をフローチャートで示した図である。
【００５９】
（ステップ７０１）プリペア指示を受取る。
【００６０】
（ステップ７０２）グループ内で決着必要なリソースアダプタＲＡ２（１５０）、ＲＡ３（１６０）をすべてプリペアする。
【００６１】
（ステップ７０３）すべて成功したかを判定する。
【００６２】
（ステップ７０４）決着用リソースマネジャＲＭ４（１８７）をプリペアする。
【００６３】
（ステップ７０５）決着用リソースマネジャＲＭ４（１８７）をロールバックする。
【００６４】
（ステップ７０６）決着用リソースマネジャＲＭ４（１８７）のプリペアが成功したか判定する。
【００６５】
（ステップ７０７）グループ内で決着必要なリソースアダプタＲＡ２（１５０）、ＲＡ３（１６０）をすべてロールバックする。
【００６６】
（ステップ７０８）プリペア成功応答を返す。
【００６７】
（ステップ７０９）プリペア失敗応答を返す。
【００６８】
図８は、リソースアダプタラッパＲＡＷ１（１１０）がコミットを行う動作をフローチャートで示した図である。
【００６９】
（ステップ８０１）コミット指示を受取る。
【００７０】
（ステップ８０２）コミット指示の内容がコミットかを判定する。
【００７１】
（ステップ８０３）決着用リソースマネジャＲＭ４（１８７）をコミットする。
【００７２】
（ステップ８０４）決着用リソースマネジャＲＭ４（１８７）をロールバックする。
【００７３】
（ステップ８０５）決着用リソースマネジャＲＭ４（１８７）のコミットが成功したかを判定する。
【００７４】
（ステップ８０６）グループ内で決着必要なリソースアダプタＲＡ２（１５０）、ＲＡ３（１６０）をすべてコミットする。
【００７５】
（ステップ８０７）グループ内で決着必要なリソースアダプタＲＡ２（１５０）、ＲＡ３（１６０）をすべてロールバックする。
【００７６】
（ステップ８０８）コミット成功応答を返す。
【００７７】
（ステップ８０９）コミット失敗応答を返す。
【００７８】
【発明の効果】
本発明により、永続記憶を持たない複数のリソースアダプタが単一のリソースマネジャを共有している場合、一相コミット最適化が可能である。
【図面の簡単な説明】
【図１】本実施例の概要の構成を示した図である。
【図２】リソース１９０がデータベースである場合の実施例を示した図である。
【図３】本実施例の装置の構成を示した図である。
【図４】リソース登録手続き１０７の動作をフローチャートで示した図である。
【図５】トランザクションマネジャ１００が行うトランザクションコミット処理をフローチャートで示した図である。
【図６】リソースアダプタラッパが一相コミットを行う動作をフローチャートで示した図である。
【図７】リソースアダプタラッパがプリペアを行う動作をフローチャートで示した図である。
【図８】リソースアダプタラッパがコミットを行う動作をフローチャートで示した図である。
【符号の説明】
１００：トランザクションマネジャ、１１０、１１５、１１７：リソースアダプタラッパ、１３０：リソースアダプタグループ管理部、１４０、１５０、１６０： リソースアダプタ、１７０：リソースマネジャラッパ、１８０、１８５、１８６、１８７：リソースマネジャ、３００：計算機、３１０：主記憶装置、３１１：オペレーティングシステム、３２０：二次記憶装置、３７０：バス、３８０：ＣＰＵ、３８１：マウス、３８２：ディスプレイ、３８３：キーボード、３８５：ネットワークインタフェース、３９０：ネットワーク
【発明の属する技術分野】
本発明は、不揮発性記憶を持たないリソースアダプタが１つのリソースマネジャを共有する分散トランザクションシステムで一相コミットを最適化する方法および装置に関する。
【０００２】
【従来の技術】
多くのデータ処理システムが導入している概念にトランザクションがある。トランザクションとは、データ処理のシーケンスを区切ってデータ処理の排他制御、障害回復などを行う管理単位である。１つのトランザクションは、処理のシーケンスの途中にトランザクション開始命令を発行した時点から、トランザクション終了命令を発行した時点までの処理のシーケンスである。トランザクション内で実行した処理はすべて実行されたか、全く実行されなかったか、のいずれかになることが保証される。これによりデータの整合性の保証が容易となる。
【０００３】
例えば、１つのデータベース内で２つのレコードを更新する場合、トランザクションを開始し、２つのレコードを更新し、トランザクションを終了することで１つのトランザクションとなる。このとき、処理が成功して必ず２つのレコードが両方とも更新されるか、処理が失敗して必ず２つのレコードが両方とも更新されないかの、いずれかであり、１つのレコードが更新され他方のレコードが更新されないということがないことがトランザクションによって保証される。いずれの場合も２つのレコード間の整合性は保証されている。
【０００４】
前記の例を実現するために、データベースはトランザクション中に行われた更新情報を主記憶上のバッファに蓄積し、トランザクション終了命令発行時にその更新情報を二次記憶に一度に書出して確定させる。途中で失敗した場合は更新情報を破棄してすべての更新を破棄し処理されなかったことにする。
【０００５】
前記の例ではデータベースが１個であったが、データベースが複数ある場合はトランザクション処理を行うためにさらに別の処理が必要である。例えば、２つのデータベースのレコードをそれぞれ更新する場合、トランザクションを開始し、データベース１のレコード１を更新し、データベース２のレコード２を更新し、トランザクションを終了することで１つのトランザンクションとするにはトランザクションを調停するトランザクションマネジャを新たに導入し、次のような処理が必要である。各々のデータベースはトランザクション中に行われた更新情報を各々の主記憶上のバッファに蓄積する。
【０００６】
トランザクション終了命令発行時には、トランザクションマネジャが調停を行う。まず、トランザクションマネジャから各々のデータベースに対してデータベースの更新情報を確定も取消しも可能な形で一旦二次記憶に一度に書出すように指示する。この処理をプリペアと呼ぶ。各々のデータベースはプリペアが成功したかどうかをトランザクションマネジャへ応答する。トランザクションマネジャは両方のデータベースのプリペアが成功した場合トランザクションログを二次記憶に書出してトランザクションが、成功したことを確定させる。
【０００７】
次に、トランザクションマネジャから各々のデータベースに対してデータベースの更新を確定させるように指示する。この処理をコミットと呼ぶ。各々のデータベースがコミットを終了したことをトランザクションマネジャへ応答するとトランザクション終了命令の処理は完了する。このようにプリペアとコミットの２段階でトランザクション終了処理を行う手順を二相コミットと呼ぶ。
【０００８】
二相コミット処理では、複数のデータベースの更新処理がすべて成功したか確認するためプリペアが必要であった。しかし、データベースが１個のみ存在する場合は、複数のデータベースについて確認する必要がないため、プリペアを省略して、トランザクションマネジャからデータベースにコミット処理するよう指示可能である。このときのコミット処理を一相コミットと呼び、一相コミットを実施することを一相コミット最適化と呼ぶ。一相コミット最適化を行った場合は、トランザクションマネジャがトランザクションログを二次記憶に書出す必要がなく、性能が向上する。
【０００９】
このような二相コミット処理するためのモデルとして、以下に述べるモデルが広く使われている（例えば、非特許文献１参照）。このモデルでは、前記の例のデータベースを一般化して、リソースマネジャと呼び、前記の例のトランザクションをグローバルトランザクションと呼ぶ。グローバルトランザクションは複数存在するので一意な識別子をつけて区別する。この識別子をグローバルトランザクション識別子と呼ぶ。トランザクションマネジャが二相コミット処理を行う対象は個々のリソースマネジャまたは、リソースマネジャをグループ化した単位で行う。この単位をトランザクションブランチと呼ぶ。トランザクションブランチを区別する識別子をブランチ修飾子と呼ぶ。
【００１０】
このモデルでは、リソースマネジャの処理をトランザクションとして行う場合リソースマネジャとトランザクションブランチを関連付けてから、リソースマネジャの処理を行う。この処理を関連付けと呼ぶ。リソースマネジャの行う一相コミット、プリペア、コミットの処理をまとめて決着と呼ぶ。関連付けはリソースマネジャごとに行われるが、決着はトランザクションブランチごとに行われる。そのため、トランザクションブランチに複数のリソースマネジャが含まれる場合は、トランザクションマネジャはそれらのリソースマネジャから任意の１つを選んで決着を行う。トランザクションに含まれるトランザクションブランチが１個場合は一相コミット最適化が実施される。
【００１１】
【非特許文献１】
X/Open Snapshot Distributed Transaction Processing:The XA+ Specification Version 2、 X/Open Company Ltd.、1994、pp.3.
【００１２】
【発明が解決しようとする課題】
本発明では、不揮発性記憶を持たず、別のリソースマネジャのデータをキャッシュするリソースマネジャをリソースアダプタと呼ぶ。複数のリソースアダプタが単一のリソースマネジャを共有して利用している構成では、実際に二次記憶に更新情報を書出す必要があるのは、単一のリソースマネジャのみであり、トランザクションマネジャのトランザクションログの書出しは不要である。従来の技術では、トランザクションマネジャが直接管理するリソースアダプタが複数存在すると、リソースアダプタの数だけトランザクションブランチが生成されて不要な二相コミット処理が行われるため、トランザクションマネジャのトランザクションログが出力され性能を低下させていた。
【００１３】
本発明の目的はこのような場合に一相コミット最適化を可能にする方法及び装置を提供することにある。
【００１４】
【課題を解決するための手段】
本発明では、以下の手順で本発明の目的を達成する。
【００１５】
同じリソースに属するリソースマネジャをグループ化して管理する。リソースアダプタをリソースアダプタラッパでラップし、前記のグループに属するリソースマネジャを利用するリソースアダプタのリソースアダプタラッパが単一のトランザクションブランチに属するようにグループ化してトランザクションマネジャに登録する。トランザクションブランチが単一になるため一相コミット最適化が実施される。決着はトランザクションブランチに含まれる任意の１個のリソースアダプタに対して行われるので、リソースマネジャグループ管理部のグループ表を参照して決着処理の呼出をグループに属するリソースアダプタへ配布する。これによってリソースマネジャの決着処理が重複して呼出されないようにするため、リソースマネジャの決着処理を呼出すリソースアダプタについては対応するリソースマネジャを決着処理では何も処理しないリソースマネジャラッパでラップする。代わりに、リソースマネジャグループ管理部が決着用リソースマネジャの決着処理を呼出して決着処理が１回だけ呼出されるようにする。
【００１６】
【発明の実施の形態】
本発明の実施形態について図面を用いて説明する。
【００１７】
図１は、本実施例の概要の構成を示した図である。
【００１８】
トランザクションマネジャ１００はグローバルトランザクション識別子ＧＴＲＩＤ１０１項目と、リソースマネジャを識別するＲＡＩＤ１０２項目と、トランザクションブランチ修飾子ＢＱＵＡＬ１０３項目を含み、レコード１０４はＧＴＲＩＤ「Ｔ１」、ＲＡＩＤ「ＲＡＷ１」、ＢＱＵＡＬ「Ｂ１」を格納し、レコード１０５はＧＴＲＩＤ「Ｔ１」、ＲＡＩＤ「ＲＡＷ２」、ＢＱＵＡＬ「Ｂ１」を格納し、レコード１０６はＧＴＲＩＤ「Ｔ１」、ＲＡＩＤ「ＲＡＷ３」、ＢＱＵＡＬ「Ｂ１」を格納する。トランザクションマネジャ１００はリソースアダプタラッパを登録するリソース登録手続き１０７を含む。
【００１９】
リソースアダプタラッパＲＡＷ１（１１０）、ＲＡＷ２（１１５）、ＲＡＷ３（１１７）は関連付け手続き１１１と、決着手続き１１２を含む。関連付け手続き１１１は対応するリソースアダプタの関連付け手続きを呼出す。決着手続き１１２は一相コミット処理、プリペア処理、コミット処理を含み、リソースマネジャグループ管理部１３０の表を参照して、対応するリソースアダプタの決着手続きを適宜呼出す。
【００２０】
リソースマネジャグループ管理部１３０はリソースアダプタラッパを識別するラッパＲＡＩＤ１３１項目と、リソースアダプタの決着処理の呼出が要不要を表す決着１３２項目と、グループを識別するグループ１３３項目を含み、レコード１３４はラッパＲＡＩＤ「ＲＡＷ１」、決着「不要」、グループ「Ｇ１」を格納し、レコード１３５はラッパＲＡＩＤ「ＲＡＷ２」、決着「必要」、グループ「Ｇ１」を格納し、レコード１３６はラッパＲＡＩＤ「ＲＡＷ３」、決着「必要」、グループ「Ｇ１」を格納する。リソースマネジャグループ管理部１３０はリソースマネジャグループを識別するグループ１３７項目と決着用リソースマネジャを識別する決着用ＲＭＩＤ１３８項目を含み、レコード１３９はグループ「Ｇ１」、決着用ＲＭＩＤ「ＲＭ４」を格納する。
【００２１】
リソースアダプタＲＡ１（１４０）は関連付け手続き１４１と、決着手続き１４２と、利用するリソースマネジャを識別する利用ＲＭＩＤ１４３項目を含み、レコード１４４は利用ＲＭＩＤ「ＲＭ１」を格納する。リソースアダプタＲＡ１（１４０）はデータを含まないため、決着手続き１４２を呼出す必要はない。
【００２２】
リソースアダプタＲＡ２（１５０）は関連付け手続き１５１と、決着手続き１５２と、利用するリソースマネジャを識別する利用ＲＭＩＤ１５３項目を含み、レコード１５４は利用ＲＭＩＤ「ＲＭ２」を格納する。リソースアダプタＲＡ２（１５０）は決着手続き１５２によって更新されるデータ１５５を含むため、決着手続き１５２を呼出す必要がある。
【００２３】
リソースアダプタＲＡ３（１６０）は関連付け手続き１６１と、決着手続き１６２と、利用するリソースマネジャを識別する利用ＲＭＩＤ１６３項目を含み、レコード１６４は利用ＲＭＩＤ「ＲＭＷ１」を格納する。リソースアダプタＲＡ３（１６０）は決着手続き１６２によって更新されるデータ１６５を含むため、決着手続き１６２を呼出す必要がある。
【００２４】
リソースマネジャラッパＲＭＷ１（１７０）は関連付け手続き１７１と、決着手続き１７２と、ラップ先リソースマネジャを識別するラップ先ＲＭＩＤ１７３項目を含み、レコード１７４はラップＲＭＩＤ「ＲＭ３」を格納する。
【００２５】
リソースマネジャＲＭ１（１８０）、ＲＭ２（１８５）、ＲＭ３（１８６）、ＲＭ４（１８７）は同一のリソース１９０に属し、関連付け手続き１８１と、決着手続き１８２を含む。
【００２６】
図２は、リソース１９０がデータベースである場合の実施例を示した図である。リソース１９０に属するリソースマネジャＲＭ１（１８０）、ＲＭ２（１８５）、ＲＭ３（１８６）、ＲＭ４（１８７）はデータベースアクセス制御２００を通じて同一のデータベース２１０をアクセスする。データベースアクセス制御２００は、グローバルトランザクションを識別するＧＴＲＩＤ２０１項目と、データベースコネクションを識別するＣＩＤ２０２項目を含み、レコード２０３はＧＴＲＩＤ「Ｔ１」、ＣＩＤ「Ｃ１」を格納する。これにより複数のリソースマネジャが共通のリソースにアクセス可能である。
【００２７】
図３は、装置の構成を示した図である。
【００２８】
計算機３０１は、主記憶装置３１０、二次記憶装置３２０、ＣＰＵ３８０、マウス３８１、ディスプレイ３８２、キーボード３８３、ネットワークインタフェース３８５、及びこれらを相互接続するバス３７０から構成される。そして、計算機３０１はネットワークインタフェース３８５を介して、ネットワーク３９０に接続される。主記憶装置３１０には、オペレーティングシステム３１１、トランザクションマネジャ１００、リソースアダプタラッパＲＡＷ１（１１０）、ＲＡＷ２（１１５）、ＲＡＷ３（１１７）、リソースアダプタグループ管理部１３０、リソースアダプタＲＡ１（１４０）、ＲＡ２（１５０）、ＲＡ３（１６０）、リソースマネジャラッパＲＭＷ１（１７０）、リソース１９０に属するリソースマネジャＲＭ１（１８０）、ＲＭ２（１８５）、ＲＭ３（１８６）、ＲＭ４（１８７）とデータベースアクセス制御２００を記憶している。二次記憶装置３２０には、データベース記憶域を記憶している。
【００２９】
図４から図８を用いて、トランザクション処理の手順の詳細を示す。トランザクションマネジャ１００はトランザクションの開始時にリソース登録手続き１０７を呼出して、リソースアダプタラッパＲＡＷ１（１１０）、ＲＡＷ２（１１５）、ＲＡＷ３（１１７）を登録する。このシーケンスは図４に示されている。トランザクションマネジャ１００はトランザクションの終了時に図５に示す処理を行い、一相コミット最適化または二相コミット処理を行う。本実施例ではトランザクションマネジャ１００が決着処理時にトランザクションブランチに含まれるリソースアダプタラッパＲＡＷ１（１１０）、ＲＡＷ２（１１５）、ＲＡＷ３（１１７）のうちリソースアダプタラッパＲＡＷ１（１１０）を選択したものとして説明する。図６に一相コミット処理でリソースアダプタラッパＲＡＷ１（１１０）が行う処理、図７にプリペア処理でリソースアダプタラッパＲＡＷ１（１１０）が行う処理、図８にコミット処理でリソースアダプタラッパＲＡＷ１（１１０）が行う処理、を示す。
【００３０】
図４は、リソース登録手続き１０７の動作をフローチャートで示した図である。リソース登録手続き１０７は、動作中のグローバルトランザクションを識別するＧＴＲＩＤと登録対象のリソースアダプタを識別するＲＡＩＤを入力とする。
【００３１】
（ステップ４０１）トランザクションマネジャ１００のテーブルに対して探索エントリを先頭に位置付ける。
【００３２】
（ステップ４０２）探索が終了したかを判定する。
【００３３】
（ステップ４０３）リソースアダプタグループ管理部１３０のテーブルのラッパＲＡＩＤ１３１項目とグループ１３３項目を参照して、登録対象のＲＡＩＤに対応するグループと探索エントリのＲＡＩＤ１０２項目に対応するグループを比較する。
【００３４】
（ステップ４０４）新しいトランザクションブランチを生成するために、新しいＢＱＵＡＬを生成して設定ＢＱＵＡＬとする。
【００３５】
（ステップ４０５）比較結果が一致を示すかを判定する。
【００３６】
（ステップ４０６）探索エントリを１つ進める。
【００３７】
（ステップ４０７）現在の探索エントリのＢＱＵＡＬを得て設定ＢＱＵＡＬとする。
【００３８】
（ステップ４０８）ＧＴＲＩＤと登録対象のＲＭＩＤと設定ＢＱＵＡＬをトランザクションマネジャのテーブルに登録する。
【００３９】
図５は、トランザクションマネジャ１００が行うトランザクションコミット処理をフローチャートで示した図である。
【００４０】
（ステップ５０１）コミット対象のトランザクションに含まれるトランザクションブランチ数を数える。
【００４１】
（ステップ５０２）トランザクションブランチ数が１かを判定する。
【００４２】
（ステップ５０３）トランザクションブランチごとに任意のリソースアダプタラッパを選び、すべてプリペアする。本実施例ではリソースアダプタラッパＲＡＷ１（１１０）を選んでプリペアする。
【００４３】
（ステップ５０４）任意のリソースアダプタラッパを選び、一相コミットする。本実施例ではリソースアダプタラッパＲＡＷ１（１１０）を選んで一相コミットする。
【００４４】
（ステップ５０５）すべてプリペア成功応答かを判定する。
【００４５】
（ステップ５０６）トランザクションブランチごとに任意のリソースアダプタラッパを選び、すべてコミット完了する。本実施例ではリソースアダプタラッパＲＡＷ１（１１０）を選んでコミット完了する。
【００４６】
（ステップ５０７）トランザクションブランチごとに任意のリソースアダプタラッパを選び、すべてロールバック完了する。本実施例ではリソースアダプタラッパＲＡＷ１（１１０）を選んでロールバック完了する。
【００４７】
図６は、リソースアダプタラッパＲＡＷ１（１１０）が一相コミットを行う動作をフローチャートで示した図である。
【００４８】
（ステップ６０１）一相コミット指示を受取る。
【００４９】
（ステップ６０２）グループ内で決着必要なリソースアダプタＲＡ２（１５０）、ＲＡ３（１６０）をすべてプリペアする。
【００５０】
（ステップ６０３）すべて成功したかを判定する。
【００５１】
（ステップ６０４）決着用リソースマネジャＲＭ４（１８７）をコミットする。
【００５２】
（ステップ６０５）決着用リソースマネジャＲＭ４（１８７）をロールバックする。
【００５３】
（ステップ６０６）決着用リソースマネジャＲＭ４（１８７）のコミットが成功したかを判定する。
【００５４】
（ステップ６０７）グループ内で決着必要なリソースアダプタＲＡ２（１５０）、ＲＡ３（１６０）をすべてコミットする。
【００５５】
（ステップ６０８）グループ内で決着必要なリソースアダプタＲＡ２（１５０）、ＲＡ３（１６０）をすべてロールバックする。
【００５６】
（ステップ６０９）一相コミット成功応答を返す。
【００５７】
（ステップ６１０）一相コミット失敗応答を返す。
【００５８】
図７は、リソースアダプタラッパＲＡＷ１（１１０）がプリペアを行う動作をフローチャートで示した図である。
【００５９】
（ステップ７０１）プリペア指示を受取る。
【００６０】
（ステップ７０２）グループ内で決着必要なリソースアダプタＲＡ２（１５０）、ＲＡ３（１６０）をすべてプリペアする。
【００６１】
（ステップ７０３）すべて成功したかを判定する。
【００６２】
（ステップ７０４）決着用リソースマネジャＲＭ４（１８７）をプリペアする。
【００６３】
（ステップ７０５）決着用リソースマネジャＲＭ４（１８７）をロールバックする。
【００６４】
（ステップ７０６）決着用リソースマネジャＲＭ４（１８７）のプリペアが成功したか判定する。
【００６５】
（ステップ７０７）グループ内で決着必要なリソースアダプタＲＡ２（１５０）、ＲＡ３（１６０）をすべてロールバックする。
【００６６】
（ステップ７０８）プリペア成功応答を返す。
【００６７】
（ステップ７０９）プリペア失敗応答を返す。
【００６８】
図８は、リソースアダプタラッパＲＡＷ１（１１０）がコミットを行う動作をフローチャートで示した図である。
【００６９】
（ステップ８０１）コミット指示を受取る。
【００７０】
（ステップ８０２）コミット指示の内容がコミットかを判定する。
【００７１】
（ステップ８０３）決着用リソースマネジャＲＭ４（１８７）をコミットする。
【００７２】
（ステップ８０４）決着用リソースマネジャＲＭ４（１８７）をロールバックする。
【００７３】
（ステップ８０５）決着用リソースマネジャＲＭ４（１８７）のコミットが成功したかを判定する。
【００７４】
（ステップ８０６）グループ内で決着必要なリソースアダプタＲＡ２（１５０）、ＲＡ３（１６０）をすべてコミットする。
【００７５】
（ステップ８０７）グループ内で決着必要なリソースアダプタＲＡ２（１５０）、ＲＡ３（１６０）をすべてロールバックする。
【００７６】
（ステップ８０８）コミット成功応答を返す。
【００７７】
（ステップ８０９）コミット失敗応答を返す。
【００７８】
【発明の効果】
本発明により、永続記憶を持たない複数のリソースアダプタが単一のリソースマネジャを共有している場合、一相コミット最適化が可能である。
【図面の簡単な説明】
【図１】本実施例の概要の構成を示した図である。
【図２】リソース１９０がデータベースである場合の実施例を示した図である。
【図３】本実施例の装置の構成を示した図である。
【図４】リソース登録手続き１０７の動作をフローチャートで示した図である。
【図５】トランザクションマネジャ１００が行うトランザクションコミット処理をフローチャートで示した図である。
【図６】リソースアダプタラッパが一相コミットを行う動作をフローチャートで示した図である。
【図７】リソースアダプタラッパがプリペアを行う動作をフローチャートで示した図である。
【図８】リソースアダプタラッパがコミットを行う動作をフローチャートで示した図である。
【符号の説明】
１００：トランザクションマネジャ、１１０、１１５、１１７：リソースアダプタラッパ、１３０：リソースアダプタグループ管理部、１４０、１５０、１６０： リソースアダプタ、１７０：リソースマネジャラッパ、１８０、１８５、１８６、１８７：リソースマネジャ、３００：計算機、３１０：主記憶装置、３１１：オペレーティングシステム、３２０：二次記憶装置、３７０：バス、３８０：ＣＰＵ、３８１：マウス、３８２：ディスプレイ、３８３：キーボード、３８５：ネットワークインタフェース、３９０：ネットワーク
Claims (1)
- トランザクションを制御するトランザクションマネジャと、
トランザクション処理において二次記憶を利用するリソースと、
前記リソースのトランザクションを制御するリソースマネジャと、
トランザクション処理において二次記憶を利用せず前記リソースマネジャを利用するリソースアダプタと、
前記リソースアダプタをラップし前記トランザクションマネジャからの指示により前記リソースアダプタのトランザクションを制御するリソースアダプタラッパと、
同じ前記リソースを利用する前記リソースアダプタのグループを管理するリソースアダプタグループ管理部、
を有するトランザクション制御システムであって、
前記リソースアダプタグループ管理部は、前記リソースアダプタラッパと、前記リソースアダプタラッパがラップする前記リソースアダプタの決着処理の要不要を示す情報と、前記グループ、の関係を格納した第一の対応表、及び、前記グループと決着用リソースマネジャの関係を格納した第二の対応表、を有し、
前記リソースアダプタの決着処理の要不要を示す情報は、該当する前記リソースアダプタの決着処理が該当する前記リソースアダプタの内部状態を変更する場合は必要、内部状態を変更しない場合は不要、であり、
前記トランザクションマネジャは、トランザクションと、前記リソースアダプタラッパと、二相コミットにおけるプリペア、コミットの処理単位であるトランザクションブランチ、の対応表を有し、
前記トランザクションマネジャは、
前記リソースアダプタラッパを前記トランザクションマネジャの対応表に登録する際に、リソースアダプタグループ管理部の前記第一の対応表を参照して、同じ前記グループに対応する前記リソースアダプタが同じ前記トランザクションブランチになるように登録する手段と、
トランザクション終了の際に、前記トランザクションマネジャの対応表に登録された前記トランザクションブランチごとに任意の前記リソースアダプタラッパを１つ選んで、前記トランザクションブランチが１個か複数個かを判定し、前記判定結果が１個の場合は前記リソースアダプタラッパに一相コミット処理を、前記判定結果が複数個の場合は前記リソースアダプタラッパにプリペア処理とコミット処理を指示する手段とを有し、
前記リソースアダプタラッパと前記リソースアダプタと前記リソースマネジャは、
ぞれぞれ、前記トランザクションブランチとの関連付け処理手段と、一相コミット処理手段と、プリペア処理手段と、コミット処理手段とを有し、
前記一相コミット処理の指示を受け、前記リソースアダプタラッパの一相コミット処理手段は、リソースアダプタグループ管理部の前記第一の対応表および前記第二の対応表を参照して、前記リソースアダプタラッパと同じ前記グループに属し決着処理の必要な前記リソースアダプタのプリペア処理手段、前記リソースアダプタラッパと同じ前記グループに対応する前記決着用リソースマネジャのコミット処理手段、前記リソースアダプタラッパと同じ前記グループに属し決着処理の必要な前記リソースアダプタのコミット処理手段、を順に呼出す手段と、
前記リソースアダプタラッパのプリペア処理手段は、リソースアダプタグループ管理部の前記第一の対応表および前記第二の対応表を参照して、前記リソースアダプタラッパと同じ前記グループに属し決着処理の必要な前記リソースアダプタのプリペア処理手段、前記リソースアダプタラッパと同じ前記グループに対応する前記決着用リソースマネジャのプリペア処理手段、を順に呼出す手段と、
前記リソースアダプタラッパのコミット処理手段は、リソースアダプタグループ管理部の対応表を参照して、前記決着用リソースマネジャのコミット処理手段、前記リソースアダプタラッパと同じ前記グループに属し決着処理の必要な前記リソースアダプタのコミット処理手段、を順に呼出す手段とを有することを特徴とするトランザクション制御システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003084092A JP4311059B2 (ja) | 2003-03-26 | 2003-03-26 | トランザクション制御方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003084092A JP4311059B2 (ja) | 2003-03-26 | 2003-03-26 | トランザクション制御方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004295272A JP2004295272A (ja) | 2004-10-21 |
| JP4311059B2 true JP4311059B2 (ja) | 2009-08-12 |
Family
ID=33399325
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003084092A Expired - Fee Related JP4311059B2 (ja) | 2003-03-26 | 2003-03-26 | トランザクション制御方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4311059B2 (ja) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4676825B2 (ja) * | 2005-06-29 | 2011-04-27 | 株式会社日立製作所 | プログラム制御方法、計算機および計算機制御プログラム |
| CN101046815A (zh) * | 2007-03-14 | 2007-10-03 | 华为技术有限公司 | 事务协调器、资源使用端、服务端及分布式事务处理方法 |
| JP2009048443A (ja) | 2007-08-21 | 2009-03-05 | Hitachi Ltd | 情報更新方法及び情報更新システム |
| US9501312B2 (en) | 2014-01-30 | 2016-11-22 | Red Hat, Inc. | Using compensation transactions for multiple one-phase commit participants |
| US9600324B2 (en) * | 2014-04-28 | 2017-03-21 | Oracle International Corporation | System and method for supporting transaction affinity based on resource manager (RM) instance awareness in a transactional environment |
| US9858312B2 (en) | 2014-10-14 | 2018-01-02 | Red Hat, Inc. | Transaction compensation for single phase resources |
-
2003
- 2003-03-26 JP JP2003084092A patent/JP4311059B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004295272A (ja) | 2004-10-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA3121919C (en) | System and method for augmenting database applications with blockchain technology | |
| US10853337B2 (en) | Lifecycle transition validation for storage objects | |
| CA2436517C (en) | Method and apparatus for data processing | |
| JP4237354B2 (ja) | トランザクション処理方法及びトランザクション処理システム | |
| RU2417426C2 (ru) | Клонирование и управление фрагментами базы данных | |
| CN104793988B (zh) | 跨数据库分布式事务的实现方法和装置 | |
| US7707186B2 (en) | Method and apparatus for data set migration | |
| JP3672208B2 (ja) | 階層化トランザクション処理方法 | |
| US20170337154A1 (en) | Storage lifecycle pipeline architecture | |
| US20050193248A1 (en) | Computer system for recovering data based on priority of the data | |
| US8977898B1 (en) | Concurrent access to data during replay of a transaction log | |
| JP2667039B2 (ja) | データ管理システムおよびデータ管理方法 | |
| JP3526474B2 (ja) | ネットワークにおける配布情報管理システム | |
| US20160314162A1 (en) | Replicable differential store data structure | |
| US7290100B2 (en) | Computer system for managing data transfer between storage sub-systems | |
| JP2005025432A (ja) | トランザクション処理方法，トランザクション制御装置およびトランザクション制御プログラム | |
| US20020004799A1 (en) | High availability database system using live/load database copies | |
| US20120072776A1 (en) | Fault isolation using code paths | |
| US20090248760A1 (en) | Backup method of computer system | |
| JP4311059B2 (ja) | トランザクション制御方法 | |
| JPH08328933A (ja) | 並列処理システムのファイルアクセス制御方式 | |
| US20180095831A1 (en) | Efficient state tracking for clusters | |
| JPH10289217A (ja) | ログ・ストリーム管理システム | |
| US20200089789A1 (en) | Systems and methods of operation lock management and system catalog overrides in database systems | |
| JPH10289141A (ja) | マルチシステム環境のログ・ストリームを管理する方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050914 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060420 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081028 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081225 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090127 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090326 |
|
| 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: 20090421 |
|
| 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: 20090504 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120522 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120522 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120522 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130522 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130522 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |