JP2007011896A - 分散トランザクションシステム - Google Patents
分散トランザクションシステム Download PDFInfo
- Publication number
- JP2007011896A JP2007011896A JP2005194357A JP2005194357A JP2007011896A JP 2007011896 A JP2007011896 A JP 2007011896A JP 2005194357 A JP2005194357 A JP 2005194357A JP 2005194357 A JP2005194357 A JP 2005194357A JP 2007011896 A JP2007011896 A JP 2007011896A
- Authority
- JP
- Japan
- Prior art keywords
- distributed transaction
- resource
- update
- status
- management device
- 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.)
- Pending
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】リソースの不整合を防止する。
【解決手段】分散トランザクションマネジャ12の分散トランザクションID通知部122が予め分散トランザクションIDをリソースマネジャ31へ通知し、リソースマネジャ31がリソース300を更新するとともに当該IDに対応づけられたステータスを更新完了を示すステータスに更新する。リソースマネジャ31から、「更新完了」の応答と「更新不能」の応答のいずれもが受け取られなかったときに、問合部123は、分散トランザクションステータス記憶部400における当該IDに対応づけられたステータスをリソースマネジャ31に問い合わせ、要求通知部121は、更新完了ステータスの回答の際にリソースマネジャ21へ「リソース更新要求」を通知し、分散トランザクション開始を示すステータスの回答の際には「ロールバック要求」を通知する。
【選択図】図1
【解決手段】分散トランザクションマネジャ12の分散トランザクションID通知部122が予め分散トランザクションIDをリソースマネジャ31へ通知し、リソースマネジャ31がリソース300を更新するとともに当該IDに対応づけられたステータスを更新完了を示すステータスに更新する。リソースマネジャ31から、「更新完了」の応答と「更新不能」の応答のいずれもが受け取られなかったときに、問合部123は、分散トランザクションステータス記憶部400における当該IDに対応づけられたステータスをリソースマネジャ31に問い合わせ、要求通知部121は、更新完了ステータスの回答の際にリソースマネジャ21へ「リソース更新要求」を通知し、分散トランザクション開始を示すステータスの回答の際には「ロールバック要求」を通知する。
【選択図】図1
Description
本発明は、リソース更新要求に対する応答の種類に応じて他のリソースについての要求の種類を決定するときに生じる可能性のあるリソースの不整合を防止する分散トランザクションシステムに関するものである。
図8は、分散トランザクションにおける2相コミット方式のシーケンス図である。
互いに整合している各リソースを1づつ管理しかつそれを更新できる場合に「準備完了」を応答する各リソースマネジャ(対応リソースマネジャ)に対し、分散トランザクションマネジャは、「準備要求(プリペア)」を通知し、「準備完了(プリペアOK)」の応答の際は、「リソース更新要求(コミット)」を通知し、これによりリソースが互いの整合を維持して更新完了し、その応答がなされるで、分散トランザクションを終了する。
図9は、「準備完了」を応答しない(または便宜的に「準備完了」を応答する)リソースマネジャ(非対応リソースマネジャ)を用いるときに採用される2相コミット方式のシーケンス図である。
更新不能を応答した非対応リソースマネジャは、リソースを更新前にロールバックするるので、分散トランザクションマネジャは、対応リソースマネジャに「ロールバック要求」を通知するべきだが、更新完了済みのリソースをロールバックしないという制約を設けることが多いので、非対応リソースマネジャではリソースがロールバックされ、一方、対応リソースマネジャではリソースが更新されるという不整合が生じる可能性がある。
そこで、図10のように、非対応リソースマネジャ数を1とし、その非対応リソースマネジャに「リソース更新要求」を通知し、「更新完了(コミットOK)」の応答の際は、対応リソースマネジャに「リソース更新要求」を通知し、一方、「更新不能(コミットNG)」の応答の際は、対応リソースマネジャに「ロールバック要求」を通知することで、不整合を防止する。非対応リソースマネジャ数を1としたのは、対応リソースマネジャへの要求の種類を非対応リソースマネジャからの回答を基に一意に決めるためである。
"Efficient commit protocols for the tree of processes model of distributed transactions",[online]、[平成17年6月1日検索]、インターネット<URL:http://portal.acm.org/citation.cfm?id=806711> "Java(登録商標) Transaction API と BEA WebLogicの拡張機能",[online]、[平成17年6月1日検索]、インターネット<URL:http://edocs.beasys.co.jp/e-docs/wls/docs81/jta/jtaapi.html>
"Efficient commit protocols for the tree of processes model of distributed transactions",[online]、[平成17年6月1日検索]、インターネット<URL:http://portal.acm.org/citation.cfm?id=806711> "Java(登録商標) Transaction API と BEA WebLogicの拡張機能",[online]、[平成17年6月1日検索]、インターネット<URL:http://edocs.beasys.co.jp/e-docs/wls/docs81/jta/jtaapi.html>
しかし、図10における非対応リソースマネジャ側の装置故障などにより、「更新完了」の応答も「更新不能」の応答のいずれもが受け取られなかったときには、対応リソースマネジャへ「リソース更新要求」と「ロールバック要求」のどちらを通知すべきかを決定できない。そのため、リソースの不整合が生じたままになる可能性がある。
本発明は、上記の課題に鑑みてなされたものであり、その目的とするところは、リソース更新要求に対する応答の種類に応じて他のリソースについての要求の種類を決定するときに生じる可能性のあるリソースの不整合を防止する分散トランザクションシステムを提供することにある。
上記の課題を解決するために、請求項1の本発明は、リソースを管理する1以上の第1リソース管理装置でない単一の第2リソース管理装置に前記リソースに整合しているリソースが管理されているときのリソースを整合を維持したまま更新する分散トランザクションにおいて第2リソース管理装置にリソース更新要求を通知し、該要求に対する更新完了の応答の際は前記第1リソース管理装置にリソース更新要求を通知する一方、更新不能の応答の際はロールバック要求を通知するときの各通知を行う要求通知部を備える分散トランザクションマネジャを備える分散トランザクション管理装置において、前記分散トランザクションを示す分散トランザクションIDに対応づけて当該分散トランザクションについてのステータスが記憶される分散トランザクションステータス記憶部が前記第2リソース管理装置に設けられるとともに当該第2リソース管理装置でのリソースの更新とともに当該分散トランザクションIDに対応づけられたステータスが更新完了を示すステータスに更新されるときの当該第2リソース管理装置に対し当該更新前に当該分散トランザクションIDを通知する分散トランザクションID通知部と、第2リソース管理装置からの前記更新完了の応答と前記更新不能の応答のいずれもが受け取られなかったときに、前記分散トランザクションステータス記憶部における前記分散トランザクションIDに対応づけられたステータスを前記第2リソース管理装置に問い合わせる問合部とを前記分散トランザクションマネジャが備え、前記要求通知部は、第1リソース管理装置への前記リソース更新要求を前記問い合わせに対する更新完了を示すステータスの回答の際に通知する一方、前記ロールバック要求を前記問い合わせに対する更新完了前を示すステータスの回答の際に通知することを特徴とする分散トランザクション管理装置をもって解決手段とする。
請求項2の本発明は、請求項1記載の第2リソース管理装置であって、該装置に管理されるリソースについての分散トランザクションを示す分散トランザクションIDと当該分散トランザクションについてのステータスが記憶される分散トランザクションステータス記憶部と、当該リソースを更新するとともに当該分散トランザクションIDに対応づけられたステータスを更新完了を示すステータスに更新し、当該ステータスの問い合わせに対し当該分散トランザクションステータス記憶部を参照して回答するリソースマネジャとを備えることを特徴とするリソース管理装置をもって解決手段とする。
請求項3の本発明は、リソースを管理する1以上の第1リソース管理装置でない単一の第2リソース管理装置に前記リソースに整合しているリソースが管理されているときのリソースを整合を維持したまま更新する分散トランザクションにおいて第2リソース管理装置にリソース更新要求を通知し、該要求に対する更新完了の応答の際は前記第1リソース管理装置にリソース更新要求を通知する一方、更新不能の応答の際はロールバック要求を通知するときの各通知を行う要求通知部を備える分散トランザクションマネジャを備える分散トランザクション管理装置が行う分散トランザクション実行方法において、前記分散トランザクションを示す分散トランザクションIDに対応づけて当該分散トランザクションについてのステータスが記憶される分散トランザクションステータス記憶部が前記第2リソース管理装置に設けられるとともに当該第2リソース管理装置でのリソースの更新とともに当該分散トランザクションIDに対応づけられたステータスが更新完了を示すステータスに更新されるときの当該第2リソース管理装置に対し、前記分散トランザクションマネジャに設けられた分散トランザクションID通知部が、当該更新前に当該分散トランザクションIDを通知し、前記分散トランザクションマネジャに設けられた問合部が、第2リソース管理装置からの前記更新完了の応答と前記更新不能の応答のいずれもが受け取られなかったときに、前記分散トランザクションステータス記憶部における前記分散トランザクションIDに対応づけられたステータスを前記第2リソース管理装置に問い合わせ、前記要求通知部が、第1リソース管理装置への前記リソース更新要求を前記問い合わせに対する更新完了を示すステータスの回答の際に通知するまたは、第1リソース管理装置への前記ロールバック要求を前記問い合わせに対する更新完了前を示すステータスの回答の際に通知することを特徴とする分散トランザクション実行方法をもって解決手段とする。
請求項4の本発明は、リソースを管理する1以上の第1リソース管理装置でない単一の第2リソース管理装置に前記リソースに整合しているリソースが管理されているときのリソースを整合を維持したまま更新する分散トランザクションにおいて第2リソース管理装置にリソース更新要求を通知し、該要求に対する更新完了の応答の際は前記第1リソース管理装置にリソース更新要求を通知する一方、更新不能の応答の際はロールバック要求を通知するときの各通知を行う要求通知部を備える分散トランザクションマネジャを備える分散トランザクション管理装置が設けられているときの分散トランザクション実行方法であって、前記分散トランザクションを示す分散トランザクションIDに対応づけて当該分散トランザクションについてのステータスが記憶される分散トランザクションステータス記憶部が設けられた前記第2リソース管理装置に対し、前記分散トランザクションマネジャに設けられた分散トランザクションID通知部が、当該更新前に当該分散トランザクションIDを通知し、前記第2リソース管理装置に設けられたリソースマネジャが、当該第2リソース管理装置でのリソースを更新するとともに前記分散トランザクションステータス記憶部において当該分散トランザクションIDに対応づけられたステータスを更新完了を示すステータスに更新し、前記分散トランザクションマネジャに設けられた問合部が、第2リソース管理装置からの前記更新完了の応答と前記更新不能の応答のいずれもが受け取られなかったときに、前記分散トランザクションステータス記憶部における前記分散トランザクションIDに対応づけられたステータスを問い合わせ、前記リソースマネジャが、当該分散トランザクションステータス記憶部を参照して回答し、前記要求通知部が、第1リソース管理装置へのリソース更新要求を前記問い合わせに対する更新完了を示すステータスの回答の際に通知するまたは、第1リソース管理装置への前記ロールバック要求を前記問い合わせに対する更新完了前を示すステータスの回答の際に通知することを特徴とする分散トランザクション実行方法をもって解決手段とする。
請求項5の本発明は、請求項1記載の分散トランザクション管理装置と請求項2記載のリソース管理装置とを備えることを特徴とする分散トランザクションシステムをもって解決手段とする。
請求項6の本発明は、請求項1記載の分散トランザクション管理装置または請求項2記載のリソース管理装置としてコンピュータを機能させるコンピュータプログラムをもって解決手段とする。
本発明によれば、分散トランザクションを示す分散トランザクションIDに対応づけて当該分散トランザクションについてのステータスが記憶される分散トランザクションステータス記憶部が第2リソース管理装置に設けられるとともに当該第2リソース管理装置でのリソースの更新とともに当該分散トランザクションIDに対応づけられたステータスが更新完了を示すステータスに更新されるときの当該第2リソース管理装置に対し当該更新前に当該分散トランザクションIDを通知し、第2リソース管理装置からの更新完了の応答と更新不能の応答のいずれもが受け取られなかったときに、分散トランザクションステータス記憶部における分散トランザクションIDに対応づけられたステータスを第2リソース管理装置に問い合わせ、第1リソース管理装置へのリソース更新要求を問い合わせに対する更新完了を示すステータスの回答の際に通知する一方、ロールバック要求を問い合わせに対する更新完了前を示すステータスの回答の際に通知することで、第2リソース管理装置からの更新完了の応答と更新不能の応答のいずれもがなかったときでも整合を維持でき、よって、リソース更新要求に対する応答の種類に応じて他のリソースについての要求の種類を決定するときに生じる可能性のあるリソースの不整合を防止することができる。
以下、本発明の実施の形態を図面を参照して説明する。
図1は、本実施の形態に係る分散トランザクションシステムの構成図である。
分散トランザクション管理装置1は、分散トランザクション管理装置1に対する双方向通信を可能に構成された第1リソース管理装置たるリソース管理装置2と、同様の双方向通信を可能に構成された第2リソース管理装置たるリソース管理装置3とに接続され、これら装置はコンピュータで構成される。
分散トランザクション管理装置1は、リソース管理装置2に接続されたデータベース(以下DB)2A内のリソース200ならびにリソース管理装置3に接続されたDB3A内のリソース300を用いた処理を行い、必要ならば各リソース管理装置2,3を制御して当該各リソース200,300を整合を維持したまま更新させるアプリケーション(以下AP)11と、このような分散トランザクションを管理する分散トランザクションマネジャ(以下TM)12と、分散トランザクションにおける経過のログが記憶されるログ記憶部13と、AP11から通知される更新内容を各コンピュータに転送する複数の転送処理部14と、ログ記憶部13から読み出されたログのヘッダが記憶更新されるログヘッダ記憶部15と、リソース不整合を回避するために行われる判定の結果が記憶される判定結果記憶部16とを備える。
リソース200は、例えば、10万円を引き出す前の銀行口座の残高情報であり、更新後のリソース200(リソース201とする)は、当該銀行口座の引き出し後の残高情報であり、この場合のリソース300は、前述の銀行口座から引き出された10万円が振り込まれる銀行口座の振り込み前の残高情報であり、更新後のリソース300(リソース301とする)は、当該銀行口座の振り込み後の残高情報である。
TM12は、ここでは、各リソース200,300を整合を維持したまま更新させるという分散トランザクションで必要な各要求を各リソース管理装置2,3に対し通知する要求通知部121と、当該分散トランザクションのような1つの分散トランザクションを示す識別情報(以下ID)である分散トランザクションIDを通知する分散トランザクションID通知部122と、リソース管理装置3からの「更新完了」の応答と「更新不能」の応答のいずれもが受け取られなかったときに、分散トランザクションのステータスを当該リソース管理装置3に問い合わせる問合部123とを備える。
リソース管理装置2は、リソースを管理するリソースマネジャ(以下RM)の中でも2相コミット方式に対応するRM(以下対応RM)として分類されるRMつまり管理するリソースを更新できる場合に「準備完了」を応答するRMであって、DB2A内のリソースを管理するRM21と、該RM21が行う処理のログが記憶されるログ記憶部22を備える。
リソース管理装置3は、対応RMではないRMとして分類されるRM(以下非対応RM)つまり「準備完了」を応答しない(または単に便宜的に「準備完了」を応答する)RMであって、DB3A内のリソースを管理するRM31を備える。
また、DB3A内には、分散トランザクションIDに対応づけて分散トランザクションについてのステータスが記憶される分散トランザクションステータス記憶部400がリソースとして設けられている。
なお、RM21の他にも同様の対応RMを使用する実施態様(以下単に他の実施態様)では、その他の対応RMを備えるリソース管理装置がログ記憶部を備え、リソース200およびリソース300に整合しているリソースが記憶されたDBが接続される。
図2は、分散トランザクションステータス記憶部400を示す図である。
分散トランザクションステータス記憶部400には、例えば、DB3Aに記憶されたリソース300の更新を含む分散トランザクションを示す分散トランザクションID「Tx1」が記憶され、さらに分散トランザクション開始を示す分散トランザクション開始ステータスが対応づけられ、当該更新のとき、当該ステータスが更新完了を示す更新完了ステータスに更新される。DB3Aに記憶された他のリソースについても同様である。
例えば、SQLを解釈するDBMS(Database Management System)を利用する場合、分散トランザクション管理装置1がリソース管理装置3に対し、以下のようなSQL文でスキーマ定義を発行することで、分散トランザクションステータス記憶部400を生成する。このSQL文は、オープンソースソフトウェアであるPostgresSQLを使う場合の記述法で記述したものである。
create table TransactionStatus(
transaction_id integer,
status integer,
PRIMARY KEY(transaction_id));
ここで、transaction_idは、分散トランザクションIDの定義である。
transaction_id integer,
status integer,
PRIMARY KEY(transaction_id));
ここで、transaction_idは、分散トランザクションIDの定義である。
なお、このcreate table文の例については、他のデータベース製品を使う場合には、intergerなどの型定義に関しては、記述法が異なる場合がある。また、「transaction_id」の型が整数(integer)である点については、トランザクション管理機能の実装により、文字列値とか、整数以外の型となる可能性がある。また、複数の属性値の組み合わせにより、分散トランザクションIDを表現する場合もある。
図3は、ログヘッダ記憶部15を示す図である。
このログヘッダ記憶部15には、例えば、ログ記憶部13に記憶されたログに含まれる分散トランザクションID「Tx1」が記憶され、そのログに含まれるヘッダが当該分散トランザクションIDに対応づけられた後、このヘッダが他のログに含まれるヘッダで逐次更新される。また、更新するヘッダが「H2」であったときは、そのヘッダを含むログ内の各RMIDが当該分散トランザクションIDに対応づけられる。ここでは、分散トランザクションIDを「Tx1」としたが、上記のPostgresSQLを使う場合の例では、これが整数となる。以下、型の違いには言及せずに説明を進める。
図4は、判定結果記憶部16を示す図である。
判定結果記憶部16には、例えば、ログヘッダ記憶部15にヘッダとともに残っている分散トランザクションID「Tx1」が記憶され、これに「ロールバック要求」必要の旨を示すフラグ(「RB」とする)または「リソース更新要求」必要の旨を示すフラグ(「UD」とする)が対応づけられる。
(本実施の形態の動作)
次に、本実施の形態の動作を説明する。
次に、本実施の形態の動作を説明する。
図5は、本実施の形態に係る分散トランザクションシステムのシーケンス図であり、図6は、分散トランザクション管理装置1のフローチャートであり、図7は、ログ記憶部13にログが追記される様子を示す図である。ここでは、分散トランザクション管理装置1とリソース管理装置2および3が起動された時点を示す起動ログ「START」がログ記憶部13に記憶され、この時点ではリソース200とリソース300が整合していることとする。また、ここでは、分散トランザクションID「Tx1」が示す分散トランザクションが起動後に開始されたこととし、その分散トランザクションについて説明するが、起動後には、他の分散トランザクションも開始され、これに対しても、同様に処理がなされる。そのときには、当該他の分散トランザクションについてのログがログ記憶部13に追記されるが、そのログについては図示省略する。
さて、分散トランザクション開始の際のAP11からの指示により、TM12は、当該開始される分散トランザクションを示す分散トランザクションID「Tx1」を生成し(図5、S1)、「分散トランザクション開始ヘッダ」であるヘッダ「H1」と分散トランザクションID「Tx1」を含むログをログ記憶部13の起動ログ「START」に続ける(S3)。
AP11からの指示でTM12は、RM21とのコネクション(コネクションCN2という)を形成し、要求通知部121はコネクションCN2を利用して、「分散トランザクション開始」と分散トランザクションID「Tx1」をRM21へ通知する(S5)。また、TM12は、「リソース追加ヘッダ」であるヘッダ「H2」、分散トランザクションID「Tx1」ならびにRM21を示すRMID(「RM21」とする)を含むログをログ記憶部13の最終のログに続ける(追記という)(S7)。
また、TM12は、そのときに使用されていない転送処理部14を1つ選択し(ここで選択されたものを転送処理部142という)、コネクションCN2に割り当てられたコネクションID(「CID2」とする)を転送処理部142に通知し、転送処理部142が選択されたことをAP11に通知する。なお、他の実施態様では、これらを他の対応RMについても行う。
また、AP11からの指示でTM12は、RM31とのコネクション(コネクションCN3という)を形成し、要求通知部121は、コネクションCN3を利用して、「分散トランザクション開始」をRM31へ通知する(S9)。なお、ここでの通知は、厳密には、S5での通知とは異なる、いわゆるローカルなトランザクションの開始の通知である。
次に、TM12は、新たなRM31とのコネクション(コネクションCN4という)を形成し、これを利用して、分散トランザクションID通知部122は、分散トランザクションID「Tx1」をRM31に通知し、続いて要求通知部121が、コネクションCN4を利用して、リソースである分散トランザクションステータス記憶部400についての更新内容、つまり、分散トランザクションID通知部122が通知したID(分散トランザクションID「Tx1」)に分散トランザクション開始を示すステータスを対応づけた状態にするという更新内容、ならびにそれについての「リソース更新要求」をRM31に通知する(S11)。
ステップS11では、分散トランザクション管理装置1がリソース管理装置3に、例えば、以下のようなSQL文を発行することで更新内容を通知する。
insert into TransactionStatus (transaction_id, status)
values($tx_id, TX_START);
$tx_id は、対象となる分散トランザクションIDであり、ここでは、$tx_id は、「Tx1」である。また、それに対応づけられたTX_STARTは、分散トランザクション開始を示すステータスである。
values($tx_id, TX_START);
$tx_id は、対象となる分散トランザクションIDであり、ここでは、$tx_id は、「Tx1」である。また、それに対応づけられたTX_STARTは、分散トランザクション開始を示すステータスである。
TM12は、ヘッダ「H2」、分散トランザクションID「Tx1」ならびにRM31を示すRMID(「RM31」とする)を含むログをログ記憶部13に追記する(S13)。
RM31は、通知された分散トランザクションIDを分散トランザクションステータス記憶部400に記憶させ、その分散トランザクションIDに分散トランザクション開始を示すステータスを対応づけ、かかる更新をコミット(更新完了)する(S14)。
次に、TM12は、そのときに使用されていない転送処理部14を1つ選択し(ここで選択されたものを転送処理部143という)、コネクションCN3に割り当てられたコネクションID(「CID3」とする)を転送処理部143に通知し、転送処理部143が選択されたことをAP11に通知する。これらは対応RMについての同様の処理に先立って行われてもよい。
次に、分散トランザクション管理装置1を使用するユーザの操作などにより、AP11は、リソース200をリソース201に更新するときの更新内容をRM21に通知する(S21)。ここでは、AP11は、転送処理部142に複数の更新内容を通知し、転送処理部142は、コネクションCN2を利用して、通知された内容をRM21に転送し、この内容をRM21はリソース管理装置2内に記憶させる。
同様に、AP11は、リソース300をリソース301に更新するときの更新内容をRM31に通知する(S23)。ここでは、AP11は、転送処理部143に複数の更新内容を通知し、転送処理部143は、コネクションCN3を利用して、通知された内容をRM31に転送し、この内容をRM31はリソース管理装置3内に記憶させる。
このように、RM31は、分散トランザクション開始後、複数の更新内容を受け付ける。RM31にとっては、分散トランザクションステータス記憶部400に記憶されたステータスの変更も更新内容の1つである。RM31は、コネクションCN3を利用して、後に「リソース更新要求」を受けることになるが、このときは、分散トランザクション開始後に、コネクションCN3を利用して受け付けた全ての更新内容について、リソース更新を同期して行う。ここで、同期したリソース更新とは、全ての更新内容が正しく更新されるか、あるいは更新されないかのいずれかになることをいう。
さて、次に、AP11からの指示でTM12は、「準備要求開始ヘッダ」であるヘッダ「H3」と分散トランザクションID「Tx1」とを含むログをログ記憶部13に追記する(S31)。
そして、要求通知部121は、コネクションCN2を利用して、「準備要求」と分散トランザクションID「Tx1」をRM21に通知する(S33)。
RM21は、この通知で更新準備を行い、つまりリソース200を読み出し、これとリソース管理装置2内に記憶させた更新内容を基に、更新後のリソース201と同じリソース(更新後イメージという)ならびに更新前のリソース200と同じリソース(更新前イメージという)を生成し、各イメージをログ記憶部22に記憶させ、TM12に「準備完了」を応答する(S35)。一方、リソース200が読み出せなかった等の理由により各イメージをログ記憶部22に記憶させることができなかったとき、RM21は、DB2Aをリソース200が記憶された状態にして、TM12に「準備不能」を応答する(S35)。
「準備不能」が応答された場合、TM12の要求通知部121は、コネクションCN3を利用して、「ロールバック要求」と分散トランザクションID「Tx1」をRM31に通知し(S37)、「ロールバックヘッダ」であるヘッダ「RBH」と分散トランザクションID「Tx1」とを含むログをログ記憶部13に追記し(S39)、処理を終える。
「ロールバック要求」を通知されたRM31は、リソース300の更新を始めていた場合はロールバックして、DB3Aをリソース300が記憶された状態に戻す。
なお、「準備不能」が応答された場合のTM12の要求通知部121は、他の実施態様では他の対応RMにも「ロールバック要求」を通知し、当該RMは同様にデータベースを基に戻す。
ステップS35で、「準備完了」が応答された場合にTM12は、あるいは他の実施態様では、RM21と他の対応RM全てから「準備完了」が応答された場合にTM12は、「準備完了ヘッダ」であるヘッダ「H4」と分散トランザクションID「Tx1」とを含むログをログ記憶部13に追記する(S41)。
次に、TM12の要求通知部121は、コネクションCN3を利用して、リソースである分散トランザクションステータス記憶部400についての更新内容、つまり、「分散トランザクションIDに分散トランザクション開始を示すステータスを対応づけた状態」を、「分散トランザクションIDにトランザクションの更新完了を示すステータスを対応づけた状態」に更新するという更新内容をRM31に通知する(S50)。
ステップS50では、分散トランザクション管理装置1がリソース管理装置3に、例えば、以下のようなSQL文を発行することで更新内容を通知する。
update TransactionStatus set status = TX_FINISH
where transaction_id = $tx_id;
$tx_id は、対象となる分散トランザクションIDであり、ここでは、$tx_id は、「Tx1」である。また、それに対応づけられたTX_FINISHは、分散トランザクションの更新完了を示すステータスである。
where transaction_id = $tx_id;
$tx_id は、対象となる分散トランザクションIDであり、ここでは、$tx_id は、「Tx1」である。また、それに対応づけられたTX_FINISHは、分散トランザクションの更新完了を示すステータスである。
これに対し、RM31は、通知された更新内容をリソース管理装置3内に記憶させる。
実際の更新は、後述する「リソース更新要求」を受けたときに、リソース300の更新と同期して行うので、ここでは、通知された更新内容をリソース管理装置3内に記憶させる。
次に、TM12の要求通知部121は、コネクションCN3を利用して、これまでにコネクションCN3を利用して通知された全ての更新内容により更新されるべき全てのリソースについての「リソース更新要求」をRM31に通知する(S51)。
これに対し、RM31は、これまでにコネクションCN3を利用して通知された全ての更新内容により更新されるべき全てのリソース(ここではリソース300と分散トランザクションステータス記憶部400)を同期して更新する。
具体的には、RM31は、リソース300を読み出し、これとリソース管理装置3内に記憶させた前記更新内容を基に、DB3Aのリソース300をリソース301に更新する(S53)とともに、分散トランザクションステータス記憶部400における分散トランザクションID「Tx1」に対応づけられたステータスを更新完了を示す更新完了ステータスに更新し(S55)、TM12に「更新完了」を応答する(S57)。一方、リソース300が読み出せなかった等の理由により更新を行えなかったとき、RM31は、DB3Aをリソース300が記憶された状態にするとともに、分散トランザクションステータス記憶部400を元の状態つまり分散トランザクションIDに分散トランザクション開始を示すステータスを対応づけた状態とし、TM12に「更新不能」を応答する(S57)。
つまり、リソース300と分散トランザクションステータス記憶部400とが共に更新完了(コミット)されるか、あるいは共に更新完了されない(更新不能)のいずれかになり、その結果が応答される。
「更新不能」が応答された場合、TM12の要求通知部121は、「ロールバック要求」と分散トランザクションID「Tx1」をRM21に通知し(S59)、ヘッダ「RBH」と分散トランザクションID「Tx1」とを含むログをログ記憶部13に追記し(S61)、処理を終える。
この「ロールバック要求」を通知されたRM21は、リソース200の更新を始めていた場合はロールバックして、DB2Aをリソース200が記憶された状態に戻す。なお、TM12の要求通知部121は、他の実施態様では他の対応RMにも「ロールバック要求」を通知し、当該RMは同様にデータベースを基に戻す。
ステップS57で、「更新完了」が応答された場合、TM12は、「更新完了ヘッダ」であるヘッダ「H5」と分散トランザクションID「Tx1」とを含むログをログ記憶部13に追記する(S63)。
次に、TM12の要求通知部121は、「リソース更新要求」と分散トランザクションID「Tx1」をRM21に通知する(S71)。RM21は、ログ記憶部22から更新後イメージを読み出し、これでDB2Aのリソース200をリソース201に更新する(S73)。
なお、TM12の要求通知部121は、他の実施態様では他の対応RMに対しても更新要求を通知し(S71)、当該RMは同様にデータベースを更新する(S73)。
さて、RM21は、DB2Aのリソース200を更新できた場合、TM12に「更新完了」を応答する(S75)。
この場合にTM12は、あるいは他の実施態様では、RM21と他のRM全てから「更新完了」が応答された場合にTM12は、「分散トランザクション終了ヘッダ」であるヘッダ「H6」と分散トランザクションID「Tx1」とを含むログをログ記憶部13に追記し(S77)、処理を終える。
さて、例えば、RM31の故障などにより、RM31がステップS57で「更新不能」と「更新完了」のいずれも応答できず、その後、RM31が故障から回復した場合、TM12は回復の通知により以下の処理を行う。あるいは、TM12が故障などにより、これらの応答を受信できなかった場合、自身の回復により以下の処理を行う。
TM12は、先ず、ログ記憶部13の起動ログ「START」を検索する(図6、S101)。
次に、起動ログ「START」以降のログの中で分散トランザクションID「Tx1」を含むものがある場合、その中で最初に記録されたログに含まれる分散トランザクションIDをログヘッダ記憶部15に記憶させるとともに、当該ログに含まれるヘッダ「H1」を当該分散トランザクションIDに対応づける(S103)。
次に、それ以降にも分散トランザクションID「Tx1」を含むログがあるか否かを判定し(S105)、そのログがある場合、その中で最初に記録されたログに含まれるヘッダで当該分散トランザクションIDに対応づけられているヘッダを更新し(S107)、そのログのヘッダが「H2」であったときは、そのログ内の各RMIDつまりRMID「RM21」およびRMID「RM31」を当該分散トランザクションID「Tx1」に対応づけ(S109)、ステップS105に戻る。
一方、分散トランザクションID「Tx1」を含むログがない場合(S105)、ログヘッダ記憶部15の分散トランザクションID「Tx1」にヘッダ「H6」またはヘッダ「RBH」が対応づけられている場合に限り、当該分散トランザクションIDおよびヘッダならびに対応づけられたRMIDを削除する(S111)。
次に、TM12は、ログヘッダ記憶部15に、分散トランザクションID「Tx1」があるか否かを判定し(S113)、ない場合は、処理を終える。
一方、ある場合は、ログヘッダ記憶部15において分散トランザクションID「Tx1」に対応づけられたヘッダを読み出す(S115)。
このヘッダがヘッダ「H1」、ヘッダ「H2」またはヘッダ「H3」の場合、判定結果記憶部16に、分散トランザクションID「Tx1」を記憶させ、これに「ロールバック要求」必要の旨を示すフラグ「RB」を対応づける(S117)。
あるいは、ステップS115で読み出したヘッダがヘッダ「H4」の場合、ログヘッダ記憶部15において分散トランザクションID「Tx1」に対応づけられたRMIDの中に非対応RMを示すものがあるか否かを判定し(S119)、ない場合、判定結果記憶部16に、分散トランザクションID「Tx1」を記憶させ、これに「リソース更新要求」必要の旨を示すフラグ「UD」を対応づける(S121)。ステップS119は、例えば、非対応RMだけのRMIDからなるリストなどを用いて行えばよい。一方、非対応RMを示すものがある場合(S119)、TM12の問合部123が、RM31に対し、分散トランザクションステータス記憶部400における分散トランザクションID「Tx1」に対応づけられたステータスを問い合わせる(S123)。
ステップS123では、分散トランザクション管理装置1がリソース管理装置3に、例えば、以下のようなSQL文を発行することでステータスを問い合わせる。
select status from TransactionStatus where transaction_id = $tx_id;
$tx_id は、対象となる分散トランザクションIDであり、ここでは、$tx_id は、「Tx1」である。
$tx_id は、対象となる分散トランザクションIDであり、ここでは、$tx_id は、「Tx1」である。
これに対しRM31は、分散トランザクションステータス記憶部400を参照して応答する。
例えば、ステップS123のSQL文に対し、RM31は、$tx_id に対応づけられたステータスを検索し、これを分散トランザクション管理装置1に送信する。
TM12は、更新完了ステータスが応答された場合、S121へ制御を移行させ、一方、分散トランザクション開始を示すステータスつまり更新完了前を示すステータスが応答された場合、S117へ制御を移行させる。
ステップS115で読み出したヘッダがヘッダ「H5」の場合、分散トランザクションID「Tx1」を記憶させ、これに「リソース更新要求」が必要である旨を示すフラグ「UD」を対応づける(S121)。
さて、ステップS117またはステップS121を終えると、TM12は、判定結果記憶部16の分散トランザクションID「Tx1」に対応づけられたフラグを読み出し(S131)、それがフラグ「UD」であった場合、制御をステップS71(図6)へ移す。 これにより、DB2Aのリソース200がリソース201に更新され(S73)、ヘッダ「H6」と分散トランザクションID「Tx1」とを含むログがログ記憶部13に追記される。つまり、DB2Aのリソース200がリソース201に更新されるとともに、DB3Aのリソース300がリソース301に更新され、結果的に、DB2AのリソースとDB3Aのリソースの整合が維持される。
一方、図7のステップS131で読み出したものがフラグ「RB」であった場合、制御をステップS59(図6)へ移す。
これにより、DB2Aはリソース200が記憶された状態になりとともに、DB3Aはリソース300が記憶された状態となり、結果的にDB2AのリソースとDB3Aのリソースの整合が維持される。
以上説明したように、本実施の形態によれば、分散トランザクションを示す分散トランザクションIDに対応づけて当該分散トランザクションについてのステータスが記憶される分散トランザクションステータス記憶部が第2リソース管理装置に設けられるとともに当該第2リソース管理装置でのリソースの更新とともに当該分散トランザクションIDに対応づけられたステータスが更新完了を示すステータスに更新されるときの当該第2リソース管理装置に対し当該更新前に当該分散トランザクションIDを通知し、第2リソース管理装置からの更新完了の応答と更新不能の応答のいずれもが受け取られなかったときに、分散トランザクションステータス記憶部における分散トランザクションIDに対応づけられたステータスを第2リソース管理装置に問い合わせ、第1リソース管理装置へのリソース更新要求を問い合わせに対する更新完了を示すステータスの回答の際に通知する一方、ロールバック要求を問い合わせに対する更新完了前を示すステータスの回答の際に通知することで、第2リソース管理装置からの更新完了の応答と更新不能の応答のいずれもがなかったときでも整合を維持でき、よって、リソース更新要求に対する応答の種類に応じて他のリソースについての要求の種類を決定するときに生じる可能性のあるリソースの不整合を防止することができる。
また、ステップS75で「更新完了」を応答された場合にTM12は、あるいは他の実施態様では、RM21と他のRM全てから「更新完了」が応答された場合にTM12は、「分散トランザクション終了」と分散トランザクションID「Tx1」をRM31へ通知し、これにより、RM31が、分散トランザクションステータス記憶部400から分散トランザクションID「Tx1」とステータスを消去することとしてもよい。
また、上記各DBは、該DBが接続されたRM装置内に含まれていてもよい。
また、本実施の形態では、分散トランザクションの指示をアプリケーションが行ったが、これをミドルウェアやプロセスが行ってもよい。
また、本実施の形態ではリソース更新を更新後イメージにより一括して行ったが、リソース更新は部分的に段階を経て行ってもよい。また、更新後イメージを用いる場合の当該イメージの記憶場所は、ログ記憶部22でなく、例えば、メモリであってもよい。また、RM21などでは、「リソース更新要求」を受けたときにリソースを更新するのでなく、「準備要求」を受けたときにリソースを更新し、その後、「ロールバック要求」を受けた場合は、更新前イメージにより、リソースを更新前の状態に戻すようにしてもよい。
また、分散トランザクション管理装置1またはリソース管理装置2としてコンピュータを機能させるコンピュータプログラムは、半導体メモリ、磁気ディスク、光ディスク、光磁気ディスク、磁気テープなどのコンピュータ読み取り可能な記録媒体に格納したり、インターネットなどの通信網を介して伝送させて、広く流通させることができる。
1…分散トランザクション管理装置
2,3…リソース管理装置
2A,3A…データベース
11…アプリケーション
12…分散トランザクションマネジャ
13,22…ログ記憶部
14,142,143…転送処理部
15…ログヘッダ記憶部
16…判定結果記憶部
21,31…リソースマネジャ
121…要求通知部
122…分散トランザクションID通知部
123…問合部
200,300…更新前リソース
201,301…更新後リソース
400…分散トランザクションステータス記憶部
2,3…リソース管理装置
2A,3A…データベース
11…アプリケーション
12…分散トランザクションマネジャ
13,22…ログ記憶部
14,142,143…転送処理部
15…ログヘッダ記憶部
16…判定結果記憶部
21,31…リソースマネジャ
121…要求通知部
122…分散トランザクションID通知部
123…問合部
200,300…更新前リソース
201,301…更新後リソース
400…分散トランザクションステータス記憶部
Claims (6)
- リソースを管理する1以上の第1リソース管理装置でない単一の第2リソース管理装置に前記リソースに整合しているリソースが管理されているときのリソースを整合を維持したまま更新する分散トランザクションにおいて第2リソース管理装置にリソース更新要求を通知し、該要求に対する更新完了の応答の際は前記第1リソース管理装置にリソース更新要求を通知する一方、更新不能の応答の際はロールバック要求を通知するときの各通知を行う要求通知部を備える分散トランザクションマネジャを備える分散トランザクション管理装置において、
前記分散トランザクションを示す分散トランザクションIDに対応づけて当該分散トランザクションについてのステータスが記憶される分散トランザクションステータス記憶部が前記第2リソース管理装置に設けられるとともに当該第2リソース管理装置でのリソースの更新とともに当該分散トランザクションIDに対応づけられたステータスが更新完了を示すステータスに更新されるときの当該第2リソース管理装置に対し当該更新前に当該分散トランザクションIDを通知する分散トランザクションID通知部と、
第2リソース管理装置からの前記更新完了の応答と前記更新不能の応答のいずれもが受け取られなかったときに、前記分散トランザクションステータス記憶部における前記分散トランザクションIDに対応づけられたステータスを前記第2リソース管理装置に問い合わせる問合部とを前記分散トランザクションマネジャが備え、
前記要求通知部は、第1リソース管理装置への前記リソース更新要求を前記問い合わせに対する更新完了を示すステータスの回答の際に通知する一方、前記ロールバック要求を前記問い合わせに対する更新完了前を示すステータスの回答の際に通知することを特徴とする分散トランザクション管理装置。 - 請求項1記載の第2リソース管理装置であって、
該装置に管理されるリソースについての分散トランザクションを示す分散トランザクションIDと当該分散トランザクションについてのステータスが記憶される分散トランザクションステータス記憶部と、
当該リソースを更新するとともに当該分散トランザクションIDに対応づけられたステータスを更新完了を示すステータスに更新し、当該ステータスの問い合わせに対し当該分散トランザクションステータス記憶部を参照して回答するリソースマネジャと
を備えることを特徴とするリソース管理装置。 - リソースを管理する1以上の第1リソース管理装置でない単一の第2リソース管理装置に前記リソースに整合しているリソースが管理されているときのリソースを整合を維持したまま更新する分散トランザクションにおいて第2リソース管理装置にリソース更新要求を通知し、該要求に対する更新完了の応答の際は前記第1リソース管理装置にリソース更新要求を通知する一方、更新不能の応答の際はロールバック要求を通知するときの各通知を行う要求通知部を備える分散トランザクションマネジャを備える分散トランザクション管理装置が行う分散トランザクション実行方法において、
前記分散トランザクションを示す分散トランザクションIDに対応づけて当該分散トランザクションについてのステータスが記憶される分散トランザクションステータス記憶部が前記第2リソース管理装置に設けられるとともに当該第2リソース管理装置でのリソースの更新とともに当該分散トランザクションIDに対応づけられたステータスが更新完了を示すステータスに更新されるときの当該第2リソース管理装置に対し、前記分散トランザクションマネジャに設けられた分散トランザクションID通知部が、当該更新前に当該分散トランザクションIDを通知し、
前記分散トランザクションマネジャに設けられた問合部が、第2リソース管理装置からの前記更新完了の応答と前記更新不能の応答のいずれもが受け取られなかったときに、前記分散トランザクションステータス記憶部における前記分散トランザクションIDに対応づけられたステータスを前記第2リソース管理装置に問い合わせ、
前記要求通知部が、第1リソース管理装置への前記リソース更新要求を前記問い合わせに対する更新完了を示すステータスの回答の際に通知するまたは、第1リソース管理装置への前記ロールバック要求を前記問い合わせに対する更新完了前を示すステータスの回答の際に通知することを特徴とする分散トランザクション実行方法。 - リソースを管理する1以上の第1リソース管理装置でない単一の第2リソース管理装置に前記リソースに整合しているリソースが管理されているときのリソースを整合を維持したまま更新する分散トランザクションにおいて第2リソース管理装置にリソース更新要求を通知し、該要求に対する更新完了の応答の際は前記第1リソース管理装置にリソース更新要求を通知する一方、更新不能の応答の際はロールバック要求を通知するときの各通知を行う要求通知部を備える分散トランザクションマネジャを備える分散トランザクション管理装置が設けられているときの分散トランザクション実行方法であって、
前記分散トランザクションを示す分散トランザクションIDに対応づけて当該分散トランザクションについてのステータスが記憶される分散トランザクションステータス記憶部が設けられた前記第2リソース管理装置に対し、前記分散トランザクションマネジャに設けられた分散トランザクションID通知部が、当該更新前に当該分散トランザクションIDを通知し、
前記第2リソース管理装置に設けられたリソースマネジャが、当該第2リソース管理装置でのリソースを更新するとともに前記分散トランザクションステータス記憶部において当該分散トランザクションIDに対応づけられたステータスを更新完了を示すステータスに更新し、
前記分散トランザクションマネジャに設けられた問合部が、第2リソース管理装置からの前記更新完了の応答と前記更新不能の応答のいずれもが受け取られなかったときに、前記分散トランザクションステータス記憶部における前記分散トランザクションIDに対応づけられたステータスを前記第2リソース管理装置に問い合わせ、
前記リソースマネジャが、当該分散トランザクションステータス記憶部を参照して回答し、
前記要求通知部が、第1リソース管理装置へのリソース更新要求を前記問い合わせに対する更新完了を示すステータスの回答の際に通知するまたは、第1リソース管理装置への前記ロールバック要求を前記問い合わせに対する更新完了前を示すステータスの回答の際に通知することを特徴とする分散トランザクション実行方法。 - 請求項1記載の分散トランザクション管理装置と請求項2記載のリソース管理装置とを備えることを特徴とする分散トランザクションシステム。
- 請求項1記載の分散トランザクション管理装置または請求項2記載のリソース管理装置としてコンピュータを機能させるコンピュータプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2005194357A JP2007011896A (ja) | 2005-07-01 | 2005-07-01 | 分散トランザクションシステム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2005194357A JP2007011896A (ja) | 2005-07-01 | 2005-07-01 | 分散トランザクションシステム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2007011896A true JP2007011896A (ja) | 2007-01-18 |
Family
ID=37750259
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2005194357A Pending JP2007011896A (ja) | 2005-07-01 | 2005-07-01 | 分散トランザクションシステム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2007011896A (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120005330A1 (en) * | 2010-06-30 | 2012-01-05 | International Business Machines Corporation | Organizing Individual Java Client Request Flows into a Single Server Transaction |
JP2016530636A (ja) * | 2013-08-29 | 2016-09-29 | ワンディスコ,インク. | コンセンサスノードを用いた分散ファイルシステム |
WO2020108325A1 (zh) * | 2018-11-27 | 2020-06-04 | 阿里巴巴集团控股有限公司 | 事务处理方法、装置和设备 |
-
2005
- 2005-07-01 JP JP2005194357A patent/JP2007011896A/ja active Pending
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120005330A1 (en) * | 2010-06-30 | 2012-01-05 | International Business Machines Corporation | Organizing Individual Java Client Request Flows into a Single Server Transaction |
US20120173721A1 (en) * | 2010-06-30 | 2012-07-05 | International Business Machines Corporation | Organizing Individual Java Client Request Flows Into A Single Server Transaction |
US8484341B2 (en) * | 2010-06-30 | 2013-07-09 | International Business Machines Corporation | Organizing individual java client request flows into a single server transaction |
US8484342B2 (en) * | 2010-06-30 | 2013-07-09 | International Business Machines Corporation | Organizing individual java client request flows into a single server transaction |
JP2016530636A (ja) * | 2013-08-29 | 2016-09-29 | ワンディスコ,インク. | コンセンサスノードを用いた分散ファイルシステム |
WO2020108325A1 (zh) * | 2018-11-27 | 2020-06-04 | 阿里巴巴集团控股有限公司 | 事务处理方法、装置和设备 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11556518B2 (en) | System and method for providing high availability data | |
CN104239439A (zh) | 选择性的数据库复制 | |
US8015151B2 (en) | Method and system for managing and modifying time dependent data structures | |
US8108344B2 (en) | Method and system for maintaining current data for wireless devices | |
JP5940074B2 (ja) | トランザクション処理システム、方法及びプログラム | |
US20020156863A1 (en) | Apparatus and methods for managing caches on a gateway | |
US20120221537A1 (en) | Solution method of in-doubt state in two-phase commit protocol of distributed transaction | |
US6470342B1 (en) | Process of maintaining a distributed map of transaction identifiers and using hashing to access these maps | |
KR20000035005A (ko) | 서버에서 고객으로의 애플리케이션 및 데이터베이스 분배 방법 및 시스템과 그를 이용하는 컴퓨터 프로그램 장치 | |
US20060259517A1 (en) | Data synchronizer with failover facility | |
JP2004528636A (ja) | 自動データ更新 | |
CN104657158B (zh) | 一种业务系统中业务处理的方法和装置 | |
KR100519689B1 (ko) | 정보 처리 시스템간 제휴 장치, 통합 정보 처리 시스템 및정보 처리 시스템간 제휴 프로그램을 기록한 기록 매체 | |
US8527995B2 (en) | Synchronization system for entities maintained by multiple applications | |
TWI439873B (zh) | Data synchronization method | |
US20060149791A1 (en) | Database-driven distributed recovery | |
JP2007011896A (ja) | 分散トランザクションシステム | |
CN109145054A (zh) | 一种管理客户端数据的方法 | |
JP2004302635A (ja) | トランザクション処理方法及びその実施装置並びにその処理プログラム | |
JP2007025982A (ja) | 分散トランザクションシステム | |
CN110069505B (zh) | 离线数据处理方法及离线数据更新装置 | |
JP2007011895A (ja) | 分散トランザクションシステム | |
JPH034339A (ja) | 分散処理システムにおけるデータベース更新方式 | |
US7739688B1 (en) | Techniques for managing distribution of well-defined objects in a client/server system | |
US20070156631A1 (en) | Synchronization of transactional applications and analytical applications |