JP2007011895A - 分散トランザクションシステム - Google Patents

Abstract

【課題】リソースの不整合を防止する。
【解決手段】分散トランザクションマネジャ１２の分散トランザクションＩＤ通知部１２２が予め分散トランザクションＩＤをリソースマネジャ３１へ通知し、リソースマネジャ３１がリソース３００を更新するとともに分散トランザクションＩＤを分散トランザクションＩＤ記憶部４００に記憶させる。リソースマネジャ３１から、「更新完了」の応答と「更新不能」の応答のいずれもが受け取られなかったときに、問合部１２３は、分散トランザクションＩＤ記憶部４００における分散トランザクションＩＤの有無をリソースマネジャ３１に問い合わせ、リソースマネジャ３１が分散トランザクションＩＤ記憶部４００を参照して回答し、要求通知部１２１は、肯定回答の際にリソースマネジャ２１へ「リソース更新要求」を通知し、否定回答の際にリソースマネジャ２１へ「ロールバック要求」を通知する。
【選択図】図１

Description

本発明は、リソース更新要求に対する応答の種類に応じて他のリソースについての要求の種類を決定するときに生じる可能性のあるリソースの不整合を防止する分散トランザクションシステムに関するものである。

図８は、分散トランザクションにおける２相コミット方式のシーケンス図である。

互いに整合している各リソースを１づつ管理しかつそれを更新できる場合に「準備完了」を応答する各リソースマネジャ（対応リソースマネジャ）に対し、分散トランザクションマネジャは、「準備要求（プリペア）」を通知し、「準備完了（プリペアＯＫ）」の応答の際は、「リソース更新要求（コミット）」を通知し、これによりリソースが互いの整合を維持して更新完了し、その応答がなされるで、分散トランザクションを終了する。

図９は、「準備完了」を応答しない（または便宜的に「準備完了」を応答する）リソースマネジャ（非対応リソースマネジャ）を用いるときに採用される２相コミット方式のシーケンス図である。

更新不能を応答した非対応リソースマネジャは、リソースを更新前にロールバックするるので、分散トランザクションマネジャは、対応リソースマネジャに「ロールバック要求」を通知するべきだが、更新完了済みのリソースをロールバックしないという制約を設けることが多いので、非対応リソースマネジャではリソースがロールバックされ、一方、対応リソースマネジャではリソースが更新されるという不整合が生じる可能性がある。

そこで、図１０のように、非対応リソースマネジャ数を１とし、その非対応リソースマネジャに「リソース更新要求」を通知し、「更新完了（コミットＯＫ）」の応答の際は、対応リソースマネジャに「リソース更新要求」を通知し、一方、「更新不能（コミットＮＧ）」の応答の際は、対応リソースマネジャに「ロールバック要求」を通知することで、不整合を防止する。非対応リソースマネジャ数を１としたのは、対応リソースマネジャへの要求の種類を非対応リソースマネジャからの回答を基に一意に決めるためである。
"Efficient commit protocols for the tree of processes model of distributed transactions",［online］、［平成１７年６月１日検索］、インターネット＜URL：http://portal.acm.org/citation.cfm?id=806711＞ "Java（登録商標） Transaction API と BEA WebLogicの拡張機能",［online］、［平成１７年６月１日検索］、インターネット＜URL：http://edocs.beasys.co.jp/e-docs/wls/docs81/jta/jtaapi.html＞

しかし、図１０における非対応リソースマネジャ側の装置故障などにより、「更新完了」の応答も「更新不能」の応答のいずれもが受け取られなかったときには、対応リソースマネジャへ「リソース更新要求」と「ロールバック要求」のどちらを通知すべきかを決定できない。そのため、リソースの不整合が生じたままになる可能性がある。

本発明は、上記の課題に鑑みてなされたものであり、その目的とするところは、リソース更新要求に対する応答の種類に応じて他のリソースについての要求の種類を決定するときに生じる可能性のあるリソースの不整合を防止する分散トランザクションシステムを提供することにある。

上記の課題を解決するために、請求項１の本発明は、リソースを管理する１以上の第１リソース管理装置でない単一の第２リソース管理装置に前記リソースに整合しているリソースが管理されているときのリソースを整合を維持したまま更新する分散トランザクションにおいて第２リソース管理装置にリソース更新要求を通知し、該要求に対する更新完了の応答の際は前記第１リソース管理装置にリソース更新要求を通知する一方、更新不能の応答の際はロールバック要求を通知するときの各通知を行う要求通知部を備える分散トランザクションマネジャを備える分散トランザクション管理装置において、前記分散トランザクションを示す分散トランザクションＩＤが記憶される分散トランザクションＩＤ記憶部が前記第２リソース管理装置に設けられるとともに当該第２リソース管理装置でのリソースの更新とともに当該分散トランザクションＩＤが当該分散トランザクションＩＤ記憶部に記憶されるときの当該第２リソース管理装置に対し当該更新前に当該分散トランザクションＩＤを通知する分散トランザクションＩＤ通知部と、第２リソース管理装置からの前記更新完了の応答と前記更新不能の応答のいずれもが受け取られなかったときに、前記分散トランザクションＩＤ記憶部における前記分散トランザクションＩＤの有無を前記第２リソース管理装置に問い合わせる問合部とを前記分散トランザクションマネジャが備え、前記要求通知部は、第１リソース管理装置への前記リソース更新要求を前記問い合わせに対する肯定回答の際に通知する一方、前記ロールバック要求を前記問い合わせに対する否定回答の際に通知することを特徴とする分散トランザクション管理装置をもって解決手段とする。

請求項２の本発明は、請求項１記載の第２リソース管理装置であって、該装置に管理されるリソースについての分散トランザクションを示す分散トランザクションＩＤが記憶される分散トランザクションＩＤ記憶部と、当該リソースを更新するとともに当該分散トランザクションＩＤを当該分散トランザクションＩＤ記憶部に記憶させ、当該分散トランザクションＩＤ記憶部における当該分散トランザクションＩＤの有無の問い合わせに対し当該分散トランザクションＩＤ記憶部を参照して回答するリソースマネジャとを備えることを特徴とするリソース管理装置をもって解決手段とする。

請求項３の本発明は、リソースを管理する１以上の第１リソース管理装置でない単一の第２リソース管理装置に前記リソースに整合しているリソースが管理されているときのリソースを整合を維持したまま更新する分散トランザクションにおいて第２リソース管理装置にリソース更新要求を通知し、該要求に対する更新完了の応答の際は前記第１リソース管理装置にリソース更新要求を通知する一方、更新不能の応答の際はロールバック要求を通知するときの各通知を行う要求通知部を備える分散トランザクションマネジャを備える分散トランザクション管理装置が行う分散トランザクション実行方法において、前記分散トランザクションを示す分散トランザクションＩＤが記憶される分散トランザクションＩＤ記憶部が前記第２リソース管理装置に設けられるとともに当該第２リソース管理装置でのリソースの更新とともに当該分散トランザクションＩＤが当該分散トランザクションＩＤ記憶部に記憶されるときの当該第２リソース管理装置に対し、前記分散トランザクションマネジャに設けられた分散トランザクションＩＤ通知部が、当該更新前に当該分散トランザクションＩＤを通知し、前記分散トランザクションマネジャに設けられた問合部が、第２リソース管理装置からの前記更新完了の応答と前記更新不能の応答のいずれもが受け取られなかったときに、前記分散トランザクションＩＤ記憶部における前記分散トランザクションＩＤの有無を前記第２リソース管理装置に問い合わせ、前記要求通知部が、第１リソース管理装置への前記リソース更新要求を前記問い合わせに対する肯定回答の際に通知するまたは、第１リソース管理装置への前記ロールバック要求を前記問い合わせに対する否定回答の際に通知することを特徴とする分散トランザクション実行方法をもって解決手段とする。

請求項４の本発明は、リソースを管理する１以上の第１リソース管理装置でない単一の第２リソース管理装置に前記リソースに整合しているリソースが管理されているときのリソースを整合を維持したまま更新する分散トランザクションにおいて第２リソース管理装置にリソース更新要求を通知し、該要求に対する更新完了の応答の際は前記第１リソース管理装置にリソース更新要求を通知する一方、更新不能の応答の際はロールバック要求を通知するときの各通知を行う要求通知部を備える分散トランザクションマネジャを備える分散トランザクション管理装置が設けられているときの分散トランザクション実行方法であって、前記分散トランザクションを示す分散トランザクションＩＤが記憶される分散トランザクションＩＤ記憶部が設けられた前記第２リソース管理装置に対し、前記分散トランザクションマネジャに設けられた分散トランザクションＩＤ通知部が、当該更新前に当該分散トランザクションＩＤを通知し、前記第２リソース管理装置に設けられたリソースマネジャが、当該第２リソース管理装置でのリソースを更新するとともに当該分散トランザクションＩＤを当該分散トランザクションＩＤ記憶部に記憶させ、前記分散トランザクションマネジャに設けられた問合部が、第２リソース管理装置からの前記更新完了の応答と前記更新不能の応答のいずれもが受け取られなかったときに、前記分散トランザクションＩＤ記憶部における前記分散トランザクションＩＤの有無を前記第２リソース管理装置に問い合わせ、前記リソースマネジャが、当該分散トランザクションＩＤ記憶部を参照して回答し、前記要求通知部が、第１リソース管理装置へのリソース更新要求を前記問い合わせに対する肯定回答の際に通知するまたは、第１リソース管理装置への前記ロールバック要求を前記問い合わせに対する否定回答の際に通知することを特徴とする分散トランザクション実行方法をもって解決手段とする。

請求項５の本発明は、請求項１記載の分散トランザクション管理装置と請求項２記載のリソース管理装置とを備えることを特徴とする分散トランザクションシステムをもって解決手段とする。

請求項６の本発明は、請求項１記載の分散トランザクション管理装置または請求項２記載のリソース管理装置としてコンピュータを機能させるコンピュータプログラムをもって解決手段とする。

本発明によれば、分散トランザクションを示す分散トランザクションＩＤが記憶される分散トランザクションＩＤ記憶部が第２リソース管理装置に設けられるとともに当該第２リソース管理装置でのリソースの更新とともに当該分散トランザクションＩＤが当該分散トランザクションＩＤ記憶部に記憶されるときの当該第２リソース管理装置に対し当該更新前に当該分散トランザクションＩＤを通知し、第２リソース管理装置からの更新完了の応答と更新不能の応答のいずれもが受け取られなかったときに、分散トランザクションＩＤ記憶部における分散トランザクションＩＤの有無を第２リソース管理装置に問い合わせ、第１リソース管理装置へのリソース更新要求を問い合わせに対する肯定回答の際に通知する一方、ロールバック要求を問い合わせに対する否定回答の際に通知することで、第２リソース管理装置からの更新完了の応答と更新不能の応答のいずれもがなかったときでも整合を維持でき、よって、リソース更新要求に対する応答の種類に応じて他のリソースについての要求の種類を決定するときに生じる可能性のあるリソースの不整合を防止することができる。

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

図１は、本実施の形態に係る分散トランザクションシステムの構成図である。

分散トランザクション管理装置１は、分散トランザクション管理装置１に対する双方向通信を可能に構成された第１リソース管理装置たるリソース管理装置２と、同様の双方向通信を可能に構成された第２リソース管理装置たるリソース管理装置３とに接続され、これら装置はコンピュータで構成される。

分散トランザクション管理装置１は、リソース管理装置２に接続されたデータベース（以下ＤＢ）２Ａ内のリソース２００ならびにリソース管理装置３に接続されたＤＢ３Ａ内のリソース３００を用いた処理を行い、必要ならば各リソース管理装置２，３を制御して当該各リソース２００，３００を整合を維持したまま更新させるアプリケーション（以下ＡＰ）１１と、このような分散トランザクションを管理する分散トランザクションマネジャ（以下ＴＭ）１２と、分散トランザクションにおける経過のログが記憶されるログ記憶部１３と、ＡＰ１１から通知される更新内容を各コンピュータに転送する複数の転送処理部１４と、ログ記憶部１３から読み出されたログのヘッダが記憶更新されるログヘッダ記憶部１５と、リソース不整合を回避するために行われる判定の結果が記憶される判定結果記憶部１６とを備える。

リソース２００は、例えば、１０万円を引き出す前の銀行口座の残高情報であり、更新後のリソース２００（リソース２０１とする）は、当該銀行口座の引き出し後の残高情報であり、この場合のリソース３００は、前述の銀行口座から引き出された１０万円が振り込まれる銀行口座の振り込み前の残高情報であり、更新後のリソース３００（リソース３０１とする）は、当該銀行口座の振り込み後の残高情報である。

ＴＭ１２は、ここでは、各リソース２００，３００を整合を維持したまま更新させるという分散トランザクションで必要な各要求を各リソース管理装置２，３に対し通知する要求通知部１２１と、当該分散トランザクションのような１つの分散トランザクションを示す識別情報（以下ＩＤ）である分散トランザクションＩＤを通知する分散トランザクションＩＤ通知部１２２と、リソース管理装置３からの「更新完了」の応答と「更新不能」の応答のいずれもが受け取られなかったときに、分散トランザクションＩＤの有無を当該リソース管理装置３に問い合わせる問合部１２３とを備える。

リソース管理装置２は、リソースを管理するリソースマネジャ（以下ＲＭ）の中でも２相コミット方式に対応するＲＭ（以下対応ＲＭ）として分類されるＲＭつまり管理するリソースを更新できる場合に「準備完了」を応答するＲＭであって、ＤＢ２Ａ内のリソースを管理するＲＭ２１と、該ＲＭ２１が行う処理のログが記憶されるログ記憶部２２を備える。

リソース管理装置３は、対応ＲＭではないＲＭとして分類されるＲＭ（以下非対応ＲＭ）つまり「準備完了」を応答しない（または単に便宜的に「準備完了」を応答する）ＲＭであって、ＤＢ３Ａ内のリソースを管理するＲＭ３１を備える。

また、ＤＢ３Ａ内には、分散トランザクションＩＤが記憶される分散トランザクションＩＤ記憶部４００がリソースとして設けられている。

なお、ＲＭ２１の他にも同様の対応ＲＭを使用する実施態様（以下単に他の実施態様）では、その他の対応ＲＭを備えるリソース管理装置がログ記憶部を備え、リソース２００およびリソース３００に整合しているリソースが記憶されたＤＢが接続される。

図２は、分散トランザクションＩＤ記憶部４００を示す図である。

分散トランザクションＩＤ記憶部４００には、例えば、ＤＢ３Ａに記憶されたリソース３００がリソース３０１に更新されたときに、その更新についての分散トランザクションを示す分散トランザクションＩＤ「Ｔｘ１」が記憶され、ＤＢ３Ａに記憶された他のリソースが更新されたときには、同様にその更新についての分散トランザクションを示す分散トランザクションＩＤ（例えば「Ｔｘ３」）が記憶される。

例えば、ＳＱＬを解釈するＤＢＭＳ(Database Management System)を利用する場合、分散トランザクション管理装置１がリソース管理装置３に対し、以下のようなＳＱＬ文でスキーマ定義を発行することで、分散トランザクションステータス記憶部４００を生成する。このＳＱＬ文は、オープンソースソフトウェアであるＰｏｓｔｇｒｅｓＳＱＬを使う場合の記述法で記述したものである。

create table TransactionStatus(
transaction_id integer,
PRIMARY KEY(transaction_id));
ここで、transaction_idは、分散トランザクションＩＤの定義である。

なお、このcreate table文の例については、他のデータベース製品を使う場合には、intergerなどの型定義に関しては、記述法が異なる場合がある。また、「transaction_id」の型が整数(integer)である点については、トランザクション管理機能の実装により、文字列値とか、整数以外の型となる可能性がある。また、複数の属性値の組み合わせにより、分散トランザクションＩＤを表現する場合もある。

図３は、ログヘッダ記憶部１５を示す図である。

このログヘッダ記憶部１５には、例えば、ログ記憶部１３に記憶されたログに含まれる分散トランザクションＩＤ「Ｔｘ１」が記憶され、そのログに含まれるヘッダが当該分散トランザクションＩＤに対応づけられた後、このヘッダが他のログに含まれるヘッダで逐次更新される。また、更新するヘッダが「Ｈ２」であったときは、そのヘッダを含むログ内の各ＲＭＩＤが当該分散トランザクションＩＤに対応づけられる。ここでは、分散トランザクションＩＤを「Ｔｘ１」としたが、上記のＰｏｓｔｇｒｅｓＳＱＬを使う場合の例では、これが整数となる。以下、型の違いには言及せずに説明を進める。

図４は、判定結果記憶部１６を示す図である。

判定結果記憶部１６には、例えば、ログヘッダ記憶部１５にヘッダとともに残っている分散トランザクションＩＤ「Ｔｘ１」が記憶され、これに「ロールバック要求」必要の旨を示すフラグ（「ＲＢ」とする）または「リソース更新要求」必要の旨を示すフラグ（「ＵＤ」とする）が対応づけられる。

（本実施の形態の動作）
次に、本実施の形態の動作を説明する。

図５は、本実施の形態に係る分散トランザクションシステムのシーケンス図であり、図６は、分散トランザクション管理装置１のフローチャートであり、図７は、ログ記憶部１３にログが追記される様子を示す図である。ここでは、分散トランザクション管理装置１とリソース管理装置２および３が起動された時点を示す起動ログ「ＳＴＡＲＴ」がログ記憶部１３に記憶され、この時点ではリソース２００とリソース３００が整合していることとする。また、ここでは、分散トランザクションＩＤ「Ｔｘ１」が示す分散トランザクションが起動後に開始されたこととし、その分散トランザクションについて説明するが、起動後には、他の分散トランザクションも開始され、これに対しても、同様に処理がなされる。そのときには、当該他の分散トランザクションについてのログがログ記憶部１３に追記されるが、そのログについては図示省略する。

分散トランザクション開始の際のＡＰ１１からの指示により、ＴＭ１２は、当該開始される分散トランザクションを示す分散トランザクションＩＤ「Ｔｘ１」を生成し（図５、Ｓ１）、「分散トランザクション開始ヘッダ」であるヘッダ「Ｈ１」と分散トランザクションＩＤ「Ｔｘ１」を含むログをログ記憶部１３の起動ログ「ＳＴＡＲＴ」に続ける（Ｓ３）。

ＡＰ１１からの指示でＴＭ１２は、ＲＭ２１とのコネクション（コネクションＣＮ２という）を形成し、要求通知部１２１はコネクションＣＮ２を利用して、「分散トランザクション開始」と分散トランザクションＩＤ「Ｔｘ１」をＲＭ２１へ通知する（Ｓ５）。また、ＴＭ１２は、「リソース追加ヘッダ」であるヘッダ「Ｈ２」、分散トランザクションＩＤ「Ｔｘ１」ならびにＲＭ２１を示すＲＭＩＤ（「ＲＭ２１」とする）を含むログをログ記憶部１３の最終のログに続ける（追記という）（Ｓ７）。

また、ＴＭ１２は、そのときに使用されていない転送処理部１４を１つ選択し（ここで選択されたものを転送処理部１４２という）、コネクションＣＮ２に割り当てられたコネクションＩＤ（「ＣＩＤ２」とする）を転送処理部１４２に通知し、転送処理部１４２が選択されたことをＡＰ１１に通知する。なお、他の実施態様では、これらを他の対応ＲＭについても行う。

また、ＡＰ１１からの指示でＴＭ１２は、ＲＭ３１とのコネクション（コネクションＣＮ３という）を形成し、要求通知部１２１は、コネクションＣＮ３を利用して、「分散トランザクション開始」をＲＭ３１へ通知する（Ｓ９）。なお、ここでの通知は、厳密には、Ｓ５での通知とは異なる、いわゆるローカルなトランザクションの開始の通知である。

次に、分散トランザクションＩＤ通知部１２２は、コネクションＣＮ３を利用して、リソースである分散トランザクションステータス記憶部４００についての更新内容、つまり、分散トランザクションステータス記憶部４００に分散トランザクションＩＤ「Ｔｘ１」を記憶させるという更新内容をＲＭ３１に通知する（Ｓ１１）。

ステップＳ１１では、分散トランザクション管理装置１がリソース管理装置３に、例えば、以下のようなＳＱＬ文を発行することで更新内容を通知する。

insert into TransactionStatus (transaction_id) values($tx_id);
$tx_id は、対象となる分散トランザクションＩＤであり、ここでは、$tx_id は、「Ｔｘ１」である。

また、ＴＭ１２は、ヘッダ「Ｈ２」、分散トランザクションＩＤ「Ｔｘ１」ならびにＲＭ３１を示すＲＭＩＤ（「ＲＭ３１」とする）を含むログをログ記憶部１３に追記する（Ｓ１３）。

なお、ＲＭ３１は、ステップＳ１１で通知された、分散トランザクションステータス記憶部４００についての更新内容、つまりトランザクションＩＤ「Ｔｘ１」を、分散トランザクションＩＤ記憶部４００に記憶させるまで保持しておく。

次に、ＴＭ１２は、そのときに使用されていない転送処理部１４を１つ選択し（ここで選択されたものを転送処理部１４３という）、コネクションＣＮ３に割り当てられたコネクションＩＤ（「ＣＩＤ３」とする）を転送処理部１４３に通知し、転送処理部１４３が選択されたことをＡＰ１１に通知する。これらは対応ＲＭについての同様の処理に先立って行われてもよい。

次に、分散トランザクション管理装置１を使用するユーザの操作などにより、ＡＰ１１は、リソース２００をリソース２０１に更新するときの更新内容をＲＭ２１に通知する（Ｓ２１）。ここでは、ＡＰ１１は、転送処理部１４２に複数の更新内容を通知し、転送処理部１４２は、コネクションＣＮ２を利用して、通知された内容をＲＭ２１に転送し、この内容をＲＭ２１はリソース管理装置２内に記憶させる。

同様に、ＡＰ１１は、リソース３００をリソース３０１に更新するときの更新内容をＲＭ３１に通知する（Ｓ２３）。ここでは、ＡＰ１１は、転送処理部１４３に複数の更新内容を通知し、転送処理部１４３は、コネクションＣＮ３を利用して、通知された内容をＲＭ３１に転送し、この内容をＲＭ３１はリソース管理装置３内に記憶させる。

このように、ＲＭ３１は、分散トランザクション開始後、複数の更新内容を受け付ける。ＲＭ３１にとっては、分散トランザクションＩＤ記憶部４００に分散トランザクションＩＤを記憶させることも更新内容の１つである。ＲＭ３１は、コネクションＣＮ３を利用して、後に「リソース更新要求」を受けることになるが、このときは、分散トランザクション開始後に、コネクションＣＮ３を利用して受け付けた全ての更新内容について、リソース更新を同期して行う。ここで、同期したリソース更新とは、全ての更新内容が正しく更新されるか、あるいは更新されないかのいずれかになることをいう。

次に、ＡＰ１１からの指示でＴＭ１２は、「準備要求開始ヘッダ」であるヘッダ「Ｈ３」と分散トランザクションＩＤ「Ｔｘ１」とを含むログをログ記憶部１３に追記する（Ｓ３１）。

そして、要求通知部１２１は、コネクションＣＮ２を利用して、「準備要求」と分散トランザクションＩＤ「Ｔｘ１」をＲＭ２１に通知する（Ｓ３３）。

ＲＭ２１は、この通知で更新準備を行い、つまりリソース２００を読み出し、これとリソース管理装置２内に記憶させた更新内容を基に、更新後のリソース２０１と同じリソース（更新後イメージという）ならびに更新前のリソース２００と同じリソース（更新前イメージという）を生成し、各イメージをログ記憶部２２に記憶させ、ＴＭ１２に「準備完了」を応答する（Ｓ３５）。一方、リソース２００が読み出せなかった等の理由により各イメージをログ記憶部２２に記憶させることができなかったとき、ＲＭ２１は、ＤＢ２Ａをリソース２００が記憶された状態にして、ＴＭ１２に「準備不能」を応答する（Ｓ３５）。

「準備不能」が応答された場合、ＴＭ１２の要求通知部１２１は、「ロールバック要求」と分散トランザクションＩＤ「Ｔｘ１」をＲＭ３１に通知し（Ｓ３７）、「ロールバックヘッダ」であるヘッダ「ＲＢＨ」と分散トランザクションＩＤ「Ｔｘ１」とを含むログをログ記憶部１３に追記し（Ｓ３９）、処理を終える。

「ロールバック要求」を通知されたＲＭ３１は、リソース３００の更新を始めていた場合はロールバックして、ＤＢ３Ａをリソース３００が記憶された状態に戻す。

なお、「準備不能」が応答された場合のＴＭ１２の要求通知部１２１は、他の実施態様では他の対応ＲＭにも「ロールバック要求」を通知し、当該ＲＭは同様にデータベースを基に戻す。

ステップＳ３５で、「準備完了」が応答された場合にＴＭ１２は、あるいは他の実施態様では、ＲＭ２１と他の対応ＲＭ全てから「準備完了」が応答された場合にＴＭ１２は、「準備完了ヘッダ」であるヘッダ「Ｈ４」と分散トランザクションＩＤ「Ｔｘ１」とを含むログをログ記憶部１３に追記する（Ｓ４１）。

次に、ＴＭ１２の要求通知部１２１は、コネクションＣＮ３を利用して、これまでにコネクションＣＮ３を利用して通知された全ての更新内容により更新されるべき全てのリソースについての「リソース更新要求」をＲＭ３１に通知する（Ｓ５１）。

これに対し、ＲＭ３１は、これまでにコネクションＣＮ３を利用して通知された全ての更新内容により更新されるべき全てのリソース（ここではリソース３００と分散トランザクションステータス記憶部４００）を同期して更新する。

具体的には、ＲＭ３１は、リソース３００を読み出し、これとリソース管理装置３内に記憶させた前記更新内容を基に、ＤＢ３Ａのリソース３００をリソース３０１に更新する（Ｓ５３）とともに、先に通知された分散トランザクションＩＤ「Ｔｘ１」を分散トランザクションＩＤ記憶部４００に記憶させ（Ｓ５５）、ＴＭ１２に「更新完了」を応答する（Ｓ５７）。一方、リソース３００が読み出せなかった等の理由により更新を行えなかったとき、ＲＭ３１は、ＤＢ３Ａをリソース３００が記憶された状態にするとともに、分散トランザクションＩＤ記憶部４００を元の状態つまり分散トランザクションＩＤが記憶されていない状態とし、ＴＭ１２に「更新不能」を応答する（Ｓ５７）。

つまり、リソース３００と分散トランザクションＩＤ記憶部４００とが共に更新完了（コミット）されるか、あるいは共に更新完了されない（更新不能）のいずれかになり、その結果が応答される。

「更新不能」が応答された場合、ＴＭ１２の要求通知部１２１は、「ロールバック要求」と分散トランザクションＩＤ「Ｔｘ１」をＲＭ２１に通知し（Ｓ５９）、ヘッダ「ＲＢＨ」と分散トランザクションＩＤ「Ｔｘ１」とを含むログをログ記憶部１３に追記し（Ｓ６１）、処理を終える。

この「ロールバック要求」を通知されたＲＭ２１は、リソース２００の更新を始めていた場合はロールバックして、ＤＢ２Ａをリソース２００が記憶された状態に戻す。なお、ＴＭ１２の要求通知部１２１は、他の実施態様では他の対応ＲＭにも「ロールバック要求」を通知し、当該ＲＭは同様にデータベースを基に戻す。

ステップＳ５７で、「更新完了」が応答された場合、ＴＭ１２は、「更新完了ヘッダ」であるヘッダ「Ｈ５」と分散トランザクションＩＤ「Ｔｘ１」とを含むログをログ記憶部１３に追記する（Ｓ６３）。

次に、ＴＭ１２の要求通知部１２１は、「リソース更新要求」と分散トランザクションＩＤ「Ｔｘ１」をＲＭ２１に通知する（Ｓ７１）。ＲＭ２１は、ログ記憶部２２から更新後イメージを読み出し、これでＤＢ２Ａのリソース２００をリソース２０１に更新する（Ｓ７３）。

なお、ＴＭ１２の要求通知部１２１は、他の実施態様では他の対応ＲＭに対しても更新要求を通知し（Ｓ７１）、当該ＲＭは同様にデータベースを更新する（Ｓ７３）。

さて、ＲＭ２１は、ＤＢ２Ａのリソース２００を更新できた場合、ＴＭ１２に「更新完了」を応答する（Ｓ７５）。

この場合にＴＭ１２は、あるいは他の実施態様では、ＲＭ２１と他のＲＭ全てから「更新完了」が応答された場合にＴＭ１２は、「分散トランザクション終了ヘッダ」であるヘッダ「Ｈ６」と分散トランザクションＩＤ「Ｔｘ１」とを含むログをログ記憶部１３に追記し（Ｓ７７）、処理を終える。

さて、例えば、ＲＭ３１の故障などにより、ＲＭ３１がステップＳ５７で「更新不能」と「更新完了」のいずれも応答できず、その後、ＲＭ３１が故障から回復した場合、あるいは、ＴＭ１２が故障などにより、これらの応答を受信できなかった場合、自身の回復により以下の処理を行う。。

この通知があった場合、ＴＭ１２は、先ず、ログ記憶部１３の起動ログ「ＳＴＡＲＴ」を検索する（図６、Ｓ１０１）。

次に、起動ログ「ＳＴＡＲＴ」以降のログの中で分散トランザクションＩＤ「Ｔｘ１」を含むものがある場合、その中で最初に記録されたログに含まれる分散トランザクションＩＤをログヘッダ記憶部１５に記憶させるとともに、当該ログに含まれるヘッダ「Ｈ１」を当該分散トランザクションＩＤに対応づける（Ｓ１０３）。

次に、それ以降にも分散トランザクションＩＤ「Ｔｘ１」を含むログがあるか否かを判定し（Ｓ１０５）、そのログがある場合、その中で最初に記録されたログに含まれるヘッダで当該分散トランザクションＩＤに対応づけられているヘッダを更新し（Ｓ１０７）、そのログのヘッダが「Ｈ２」であったときは、そのログ内の各ＲＭＩＤつまりＲＭＩＤ「ＲＭ２１」およびＲＭＩＤ「ＲＭ３１」を当該分散トランザクションＩＤ「Ｔｘ１」に対応づけ（Ｓ１０９）、ステップＳ１０５に戻る。

一方、分散トランザクションＩＤ「Ｔｘ１」を含むログがない場合（Ｓ１０５）、ログヘッダ記憶部１５の分散トランザクションＩＤ「Ｔｘ１」にヘッダ「Ｈ６」またはヘッダ「ＲＢＨ」が対応づけられている場合に限り、当該分散トランザクションＩＤおよびヘッダならびに対応づけられたＲＭＩＤを削除する（Ｓ１１１）。

次に、ＴＭ１２は、ログヘッダ記憶部１５に、分散トランザクションＩＤ「Ｔｘ１」があるか否かを判定し（Ｓ１１３）、ない場合は、処理を終える。

一方、ある場合は、ログヘッダ記憶部１５において分散トランザクションＩＤ「Ｔｘ１」に対応づけられたヘッダを読み出す（Ｓ１１５）。

このヘッダがヘッダ「Ｈ１」、ヘッダ「Ｈ２」またはヘッダ「Ｈ３」の場合、判定結果記憶部１６に、分散トランザクションＩＤ「Ｔｘ１」を記憶させ、これに「ロールバック要求」必要の旨を示すフラグ「ＲＢ」を対応づける（Ｓ１１７）。

あるいは、ステップＳ１１５で読み出したヘッダがヘッダ「Ｈ４」の場合、の場合、ログヘッダ記憶部１５において分散トランザクションＩＤ「Ｔｘ１」に対応づけられたＲＭＩＤの中に非対応ＲＭを示すものがあるか否かを判定し（Ｓ１１９）、ない場合、判定結果記憶部１６に、分散トランザクションＩＤ「Ｔｘ１」を記憶させ、これに「リソース更新要求」必要の旨を示すフラグ「ＵＤ」を対応づける（Ｓ１２１）。ステップＳ１１９は、例えば、非対応ＲＭだけのＲＭＩＤからなるリストなどを用いて行えばよい。一方、非対応ＲＭを示すものがある場合（Ｓ１１９）、ＴＭ１２の問合部１２３が、ＲＭ３１に対し、分散トランザクションＩＤ記憶部４００における分散トランザクションＩＤ「Ｔｘ１」の有無を問い合わせる（Ｓ１２３）。

ステップＳ１２３では、分散トランザクション管理装置１がリソース管理装置３に、例えば、以下のようなＳＱＬ文を発行することで分散トランザクションＩＤの有無を問い合わせる。

select * from TransactionStatus where transaction_id = $tx_id;
$tx_id は、対象となる分散トランザクションＩＤであり、ここでは、$tx_id は、「Ｔｘ１」である。

これに対しＲＭ３１は、分散トランザクションＩＤ記憶部４００を参照して応答する。 例えば、ＳＱＬ文に対し、ＲＭ３１は、$tx_id と同じものを検索し、１件検索された場合は、「肯定応答」を行い、０件検索された場合は、「否定応答」を行う。

ＴＭ１２は、分散トランザクションＩＤ「Ｔｘ１」が分散トランザクションＩＤ記憶部４００にあることが応答（肯定応答）された場合、Ｓ１２１へ制御を移行させ、一方、ないことが応答（否定応答）された場合、Ｓ１１７へ制御を移行させる。

ステップＳ１１５で読み出したヘッダがヘッダ「Ｈ５」の場合、分散トランザクションＩＤ「Ｔｘ１」を記憶させ、これに「リソース更新要求」が必要である旨を示すフラグ「ＵＤ」を対応づける（Ｓ１２１）。

さて、ステップＳ１１７またはステップＳ１２１を終えると、ＴＭ１２は、判定結果記憶部１６の分散トランザクションＩＤ「Ｔｘ１」に対応づけられたフラグを読み出し（Ｓ１３１）、それがフラグ「ＵＤ」であった場合、制御をステップＳ７１（図６）へ移す。 これにより、ＤＢ２Ａのリソース２００がリソース２０１に更新され（Ｓ７３）、ヘッダ「Ｈ６」と分散トランザクションＩＤ「Ｔｘ１」とを含むログがログ記憶部１３に追記される。つまり、ＤＢ２Ａのリソース２００がリソース２０１に更新されるとともに、ＤＢ３Ａのリソース３００がリソース３０１に更新され、結果的に、ＤＢ２ＡのリソースとＤＢ３Ａのリソースの整合が維持される。

一方、図７のステップＳ１３１で読み出したものがフラグ「ＲＢ」であった場合、制御をステップＳ５９（図６）へ移す。

これにより、ＤＢ２Ａはリソース２００が記憶された状態になりとともに、ＤＢ３Ａはリソース３００が記憶された状態となり、結果的にＤＢ２ＡのリソースとＤＢ３Ａのリソースの整合が維持される。

以上説明したように、本実施の形態によれば、分散トランザクションを示す分散トランザクションＩＤが記憶される分散トランザクションＩＤ記憶部が第２リソース管理装置に設けられるとともに当該第２リソース管理装置でのリソースの更新とともに当該分散トランザクションＩＤが当該分散トランザクションＩＤ記憶部に記憶されるときの当該第２リソース管理装置に対し当該更新前に当該分散トランザクションＩＤを通知し、第２リソース管理装置からの更新完了の応答と更新不能の応答のいずれもが受け取られなかったときに、分散トランザクションＩＤ記憶部における分散トランザクションＩＤの有無を第２リソース管理装置に問い合わせ、第１リソース管理装置へのリソース更新要求を問い合わせに対する肯定回答の際に通知する一方、ロールバック要求を問い合わせに対する否定回答の際に通知することで、第２リソース管理装置からの更新完了の応答と更新不能の応答のいずれもがなかったときでも整合を維持でき、よって、リソース更新要求に対する応答の種類に応じて他のリソースについての要求の種類を決定するときに生じる可能性のあるリソースの不整合を防止することができる。

なお、本実施の形態のＲＭ２１や他の対応ＲＭが、「分散トランザクション開始」の通知（Ｓ５）により更新準備を行うものである場合には、「準備要求」の通知（Ｓ５３）は不要である。

また、ステップＳ７５で「更新完了」を応答された場合にＴＭ１２は、あるいは他の実施態様では、ＲＭ２１と他のＲＭ全てから「更新完了」が応答された場合にＴＭ１２は、「分散トランザクション終了」と分散トランザクションＩＤ「Ｔｘ１」をＲＭ３１へ通知し、これにより、ＲＭ３１が、分散トランザクションＩＤ記憶部４００から分散トランザクションＩＤ「Ｔｘ１」を消去することとしてもよい。

また、上記各ＤＢは、該ＤＢが接続されたＲＭ装置内に含まれていてもよい。

また、本実施の形態では、分散トランザクションの指示をアプリケーションが行ったが、これをミドルウェアやプロセスが行ってもよい。

また、本実施の形態ではリソース更新を更新後イメージにより一括して行ったが、リソース更新は部分的に段階を経て行ってもよい。また、更新後イメージを用いる場合の当該イメージの記憶場所は、ログ記憶部２２でなく、例えば、メモリであってもよい。また、ＲＭ２１などでは、「リソース更新要求」を受けたときにリソースを更新するのでなく、「準備要求」を受けたときにリソースを更新し、その後、「ロールバック要求」を受けた場合は、更新前イメージにより、リソースを更新前の状態に戻すようにしてもよい。

また、分散トランザクション管理装置１またはリソース管理装置２としてコンピュータを機能させるコンピュータプログラムは、半導体メモリ、磁気ディスク、光ディスク、光磁気ディスク、磁気テープなどのコンピュータ読み取り可能な記録媒体に格納したり、インターネットなどの通信網を介して伝送させて、広く流通させることができる。

本実施の形態に係る分散トランザクションシステムの構成図である。 分散トランザクションＩＤ記憶部４００を示す図である。 ログヘッダ記憶部１５を示す図である。 判定結果記憶部１６を示す図である。 本実施の形態に係る分散トランザクションシステムのシーケンス図である。 分散トランザクション管理装置１のフローチャートである。 ログ記憶部１３にログが追記される様子を示す図である 分散トランザクションシステムにおける２相コミット方式のシーケンス図である。 非対応リソースマネジャを用いるときのシーケンス図である。 図９のシーケンスで生じる可能性のあるリソース不整合を防止するときのシーケンス図である。

符号の説明

１…分散トランザクション管理装置
２，３…リソース管理装置
２Ａ，３Ａ…データベース
１１…アプリケーション
１２…分散トランザクションマネジャ
１３，２２…ログ記憶部
１４，１４２，１４３…転送処理部
１５…ログヘッダ記憶部
１６…判定結果記憶部
２１，３１…リソースマネジャ
１２１…要求通知部
１２２…分散トランザクションＩＤ通知部
１２３…問合部
２００，３００…更新前リソース
２０１，３０１…更新後リソース
４００…分散トランザクションＩＤ記憶部

Claims (6)

1. リソースを管理する１以上の第１リソース管理装置でない単一の第２リソース管理装置に前記リソースに整合しているリソースが管理されているときのリソースを整合を維持したまま更新する分散トランザクションにおいて第２リソース管理装置にリソース更新要求を通知し、該要求に対する更新完了の応答の際は前記第１リソース管理装置にリソース更新要求を通知する一方、更新不能の応答の際はロールバック要求を通知するときの各通知を行う要求通知部を備える分散トランザクションマネジャを備える分散トランザクション管理装置において、
   前記分散トランザクションを示す分散トランザクションＩＤが記憶される分散トランザクションＩＤ記憶部が前記第２リソース管理装置に設けられるとともに当該第２リソース管理装置でのリソースの更新とともに当該分散トランザクションＩＤが当該分散トランザクションＩＤ記憶部に記憶されるときの当該第２リソース管理装置に対し当該更新前に当該分散トランザクションＩＤを通知する分散トランザクションＩＤ通知部と、
   第２リソース管理装置からの前記更新完了の応答と前記更新不能の応答のいずれもが受け取られなかったときに、前記分散トランザクションＩＤ記憶部における前記分散トランザクションＩＤの有無を前記第２リソース管理装置に問い合わせる問合部とを前記分散トランザクションマネジャが備え、
   前記要求通知部は、第１リソース管理装置への前記リソース更新要求を前記問い合わせに対する肯定回答の際に通知する一方、前記ロールバック要求を前記問い合わせに対する否定回答の際に通知することを特徴とする分散トランザクション管理装置。
2. 請求項１記載の第２リソース管理装置であって、
   該装置に管理されるリソースについての分散トランザクションを示す分散トランザクションＩＤが記憶される分散トランザクションＩＤ記憶部と、
   当該リソースを更新するとともに当該分散トランザクションＩＤを当該分散トランザクションＩＤ記憶部に記憶させ、当該分散トランザクションＩＤ記憶部における当該分散トランザクションＩＤの有無の問い合わせに対し当該分散トランザクションＩＤ記憶部を参照して回答するリソースマネジャと
   を備えることを特徴とするリソース管理装置。
3. リソースを管理する１以上の第１リソース管理装置でない単一の第２リソース管理装置に前記リソースに整合しているリソースが管理されているときのリソースを整合を維持したまま更新する分散トランザクションにおいて第２リソース管理装置にリソース更新要求を通知し、該要求に対する更新完了の応答の際は前記第１リソース管理装置にリソース更新要求を通知する一方、更新不能の応答の際はロールバック要求を通知するときの各通知を行う要求通知部を備える分散トランザクションマネジャを備える分散トランザクション管理装置が行う分散トランザクション実行方法において、
   前記分散トランザクションを示す分散トランザクションＩＤが記憶される分散トランザクションＩＤ記憶部が前記第２リソース管理装置に設けられるとともに当該第２リソース管理装置でのリソースの更新とともに当該分散トランザクションＩＤが当該分散トランザクションＩＤ記憶部に記憶されるときの当該第２リソース管理装置に対し、前記分散トランザクションマネジャに設けられた分散トランザクションＩＤ通知部が、当該更新前に当該分散トランザクションＩＤを通知し、
   前記分散トランザクションマネジャに設けられた問合部が、第２リソース管理装置からの前記更新完了の応答と前記更新不能の応答のいずれもが受け取られなかったときに、前記分散トランザクションＩＤ記憶部における前記分散トランザクションＩＤの有無を前記第２リソース管理装置に問い合わせ、
   前記要求通知部が、第１リソース管理装置への前記リソース更新要求を前記問い合わせに対する肯定回答の際に通知するまたは、第１リソース管理装置への前記ロールバック要求を前記問い合わせに対する否定回答の際に通知することを特徴とする分散トランザクション実行方法。
4. リソースを管理する１以上の第１リソース管理装置でない単一の第２リソース管理装置に前記リソースに整合しているリソースが管理されているときのリソースを整合を維持したまま更新する分散トランザクションにおいて第２リソース管理装置にリソース更新要求を通知し、該要求に対する更新完了の応答の際は前記第１リソース管理装置にリソース更新要求を通知する一方、更新不能の応答の際はロールバック要求を通知するときの各通知を行う要求通知部を備える分散トランザクションマネジャを備える分散トランザクション管理装置が設けられているときの分散トランザクション実行方法であって、
   前記分散トランザクションを示す分散トランザクションＩＤが記憶される分散トランザクションＩＤ記憶部が設けられた前記第２リソース管理装置に対し、前記分散トランザクションマネジャに設けられた分散トランザクションＩＤ通知部が、当該更新前に当該分散トランザクションＩＤを通知し、
   前記第２リソース管理装置に設けられたリソースマネジャが、当該第２リソース管理装置でのリソースを更新するとともに当該分散トランザクションＩＤを当該分散トランザクションＩＤ記憶部に記憶させ、
   前記分散トランザクションマネジャに設けられた問合部が、第２リソース管理装置からの前記更新完了の応答と前記更新不能の応答のいずれもが受け取られなかったときに、前記分散トランザクションＩＤ記憶部における前記分散トランザクションＩＤの有無を前記第２リソース管理装置に問い合わせ、
   前記リソースマネジャが、当該分散トランザクションＩＤ記憶部を参照して回答し、
   前記要求通知部が、第１リソース管理装置へのリソース更新要求を前記問い合わせに対する肯定回答の際に通知するまたは、第１リソース管理装置への前記ロールバック要求を前記問い合わせに対する否定回答の際に通知することを特徴とする分散トランザクション実行方法。
5. 請求項１記載の分散トランザクション管理装置と請求項２記載のリソース管理装置とを備えることを特徴とする分散トランザクションシステム。
6. 請求項１記載の分散トランザクション管理装置または請求項２記載のリソース管理装置としてコンピュータを機能させるコンピュータプログラム。

Images