JP2007025982A - 分散トランザクションシステム - 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(
ap_id integer, status integer, PRIMARY KEY(transaction_id));
ここで、transaction_idは、ＡＰＩＤの定義である。

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

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

このログヘッダ記憶部１５には、ログ記憶部１３に記憶されたログに含まれる分散トランザクションのＩＤ（以下、適宜ＴｘＩＤと略す）である、例えばＴｘＩＤ「Ｔｘ１」が記憶され、そのログに含まれるヘッダが当該ＴｘＩＤに対応づけられた後、このヘッダが当該ＴｘＩＤを含む他のログに含まれるヘッダで逐次更新される。また、更新するヘッダが「Ｈ２」または「Ｈ２１」であったときは、そのヘッダを含むログ内の各ＲＭのＩＤ（以下、適宜ＲＭＩＤと略す）が当該ＴｘＩＤに対応づけられる。また、更新するヘッダが「Ｈ２１」であったときは、そのヘッダを含むログ内のＡＰＩＤつまり当該分散トランザクションの指示元であるＡＰのＡＰＩＤが対応づけられる。他の分散トランザクションとＡＰの組についても同様である。

同図は、ヘッダ「Ｈ２」がヘッダ「Ｈ２１」に更新され、既に記憶されていたＲＭＩＤ２１のＲＭＩＤ（「ＲＭ２１」とする）に加えてＲＭＩＤ３１のＲＭＩＤ（「ＲＭ３１」とする）がさらに記憶され、そのときＡＰＩＤ「１１ａ」が記憶されたときのログヘッダ記憶部１５を示している。ここでは、ＡＰＩＤを「１１ａ」としたが、上記のＰｏｓｔｇｒｅｓＳＱＬを使う場合の例では、これが整数となる。以下、型の違いには言及せずに説明を進める。

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

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

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

図５は、本実施の形態に係る分散トランザクションシステムのシーケンス図であり、図６は、分散トランザクション管理装置１のフローチャートであり、図７は、ログ記憶部１３にログが追記される様子を示す図である。ここでは、ログ記憶部１３に、リソース２００とリソース３００の整合が確認された時点を示す起動ログ「ＳＴＡＲＴ」が記憶されていることとする。

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

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

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

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

次に、ＴＭ１２は、新たなＲＭ３１とのコネクション（コネクションＣＮ４という）を形成し、これを利用して、アプリケーションＩＤ通知部１２２は、ＡＰＩＤ「１１ａ」をＲＭ３１に通知し、続いて要求通知部１２１が、コネクションＣＮ４を利用して、リソースである分散トランザクションステータス記憶部４００についての更新内容、つまり、アプリケーションＩＤ通知部１２２が通知したＡＰＩＤ（「１１ａ」）に分散トランザクション開始を示すステータスを対応づけた状態にするという更新内容、ならびにそれについての「リソース更新要求」をＲＭ３１に通知する（Ｓ１１）。

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

update TransactionStatus set status = TX_START where ap_id = $ap_id;
$ap_idは、対象となるＡＰＩＤであり、ここでは、$ap_idは、「１１ａ」である。また、それに対応づけられたTX_STARTは、分散トランザクション開始を示すステータスである。

また、ＴＭ１２は、「非対応リソース追加ヘッダ」であるヘッダ「Ｈ２１」、ＴｘＩＤ「Ｔｘ１」、ＡＰＩＤ「１１ａ」ならびにＲＭＩＤ「ＲＭ３１」を含むログをログ記憶部１３に追記する（Ｓ１３）。

ＲＭ３１は、分散トランザクションステータス記憶部４００において、ステップＳ１１のＳＱＬ文で通知されたＡＰＩＤの有無を判定し、当該ＡＰＩＤがある場合は、当該ＡＰＩＤに更新完了ステータスまたはロールバックを示すステータスが対応づけられているので、この更新完了ステータスを分散トランザクション開始を示すステータスで更新し、かかる更新をコミット（更新完了）する（Ｓ１４）。

一方、ＳＱＬ文で通知されたＡＰＩＤがない場合は、エラー応答を行う。

エラー応答があった場合、分散トランザクション管理装置１がリソース管理装置３に、例えば、以下のようなＳＱＬ文を発行することで、ＡＰＩＤを分散トランザクションステータス記憶部４００記憶させるという内容を通知する。

insert into TransactionStatus (ap_id, status)
values ($ap_id, TX_START);
ＲＭ３１は、当該ＳＱＬ文で通知されたＡＰＩＤを分散トランザクションステータス記憶部４００に記憶させ、このＡＰＩＤに分散トランザクション開始を示すステータスを対応づける更新を行い、かかる更新をコミット（更新完了）する。

なお、ステップＳ１４で初めて記憶させるＡＰＩＤを予め分散トランザクションステータス記憶部４００に記憶させるとともにそのＡＰＩＤに対応づけてステータスの領域を作成しておき、ステップＳ１４では、その領域に分散トランザクション開始を示すステータスを記憶させるようにしてもよい。

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

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

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

Ｍ３１に転送し、この内容をＲＭ３１はリソース管理装置３内に記憶させる。

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

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

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

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

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

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

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

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

次に、ＴＭ１２の要求通知部１２１は、コネクションＣＮ３を利用して、リソースである分散トランザクションステータス記憶部４００についての更新内容、つまり、「アプリケーションＩＤにトランザクション開始を示すステータスを対応づけた状態」を、「アプリケーションＩＤにトランザクションの更新完了を示すステータスを対応づけた状態」に更新するという更新内容をＲＭ３１に通知する（Ｓ５０）。

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

update TransactionStatus set status = TX_FINISH where ap_id = $ap_id;
$ap_idは、対象となるＡＰＩＤであり、ここでは、$ap_idは、「１１ａ」である。また、それに対応づけられたTX_FINISHは、分散トランザクションの更新完了を示すステータスである。

これに対し、ＲＭ３１は、通知された更新内容をリソース管理装置３内に記憶させる。実際の更新は、後述する「リソース更新要求」を受けたときに、リソース３００の更新と同期して行うので、ここでは、通知された更新内容をリソース管理装置２内に記憶させる。

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

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

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

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

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

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

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

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

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

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

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

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

ＴＭ１２は、まず、ログ記憶部１３の起動ログ「ＳＴＡＲＴ」を検索する（図６、Ｓ１０１）。

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

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

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

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

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

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

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

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

select status from TransactionStatus where transaction_id = $ap_id;
$ap_idは、対象となるＡＰＩＤであり、ここでは、$ap_idは、「１１ａ」である。なお、ステップＳ１２３では、ＴｘＩＤ「Ｔｘ１」とＡＰＩＤ「１１ａ」を通知してもよい。

これに対しＲＭ３１は、分散トランザクションステータス記憶部４００を参照して応答する。

例えば、ステップＳ１２３のＳＱＬ文に対し、ＲＭ３１は、$ap_id に対応づけられたステータスを検索し、これを分散トランザクション管理装置１に送信する。

ＴＭ１２は、更新完了ステータスが応答された場合、Ｓ１２１へ制御を移行させ、一方、分散トランザクション開始を示すステータスまたはロールバックを示すステータスつまり更新完了前を示すステータスが応答された場合、Ｓ１１７へ制御を移行させる。

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

さて、ステップＳ１１７またはステップＳ１２１を終えると、ＴＭ１２は、判定結果記憶部１６のＴｘＩＤ「Ｔｘ１」に対応づけられたフラグを読み出し（Ｓ１３１）、それがフラグ「ＵＤ」であった場合、制御をステップＳ７１（図６）へ移す。

これにより、ＤＢ２Ａのリソース２００がリソース２０１に更新され（Ｓ７３）、ヘッダ「Ｈ６」とＴｘＩＤ「Ｔｘ１」を含むログがログ記憶部１３に追記される。つまり、ＤＢ２Ａのリソース２００がリソース２０１に更新されるとともに、ＤＢ３Ａのリソース３００がリソース３０１に更新され、結果的に、ＤＢ２ＡのリソースとＤＢ３Ａのリソースの整合が維持される。

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

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

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

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

また、本実施の形態ではリソース更新を更新後イメージにより一括して行ったが、リソース更新は部分的に段階を経て行ってもよい。

また、本実施の形態では、分散トランザクションの指示をアプリケーションが行ったが、これをミドルウェアによって行い、ＡＰＩＤの代わりに、プロセス、スレッドなど、トランザクションを一意に特定可能な指示元を示すＩＤを用いるなど、かかる変形に応じた態様での実施を行ってもよい。また、更新後イメージを用いる場合の当該イメージの記憶場所は、ログ記憶部２２でなく、例えば、メモリであってもよい。また、ＲＭ２１などでは、「リソース更新要求」を受けたときにリソースを更新するのでなく、「準備要求」を受けたときにリソースを更新し、その後、「ロールバック要求」を受けた場合は、更新前イメージにより、リソースを更新前の状態に戻すようにしてもよい。

また、本実施の形態では、ＲＭ３１が、リソース３００が読み出せなかった等の理由により更新を行えなかったとき、分散トランザクションステータス記憶部４００に記憶されたＡＰＩＤにロールバックを示すステータスを対応づけた（Ｓ５７）が、当該ステータスを対応づける代わりに、ＡＰＩＤに分散トランザクション開始を示すステータスを対応づけた場合であっても、ステップＳ１１７が行われるので、かかる実施態様としてもよい。

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

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

符号の説明

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

Claims (6)

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

Images