(57)【特許請求の範囲】
【請求項１】
第１のリソースを管理する第１のリソースマネージャと、第２のリソースを管理する第２のリソースマネージャと、トランザクションマネージャとによって構成されるトランザクション処理システムであって、
前記第１のリソースマネージャは、
前記第１のリソースに第１の形態で確定的に格納されているデータを、共通鍵で暗号化した形態で、前記第２のリソースマネージャに送信するデータ送信手段と、
前記第２のリソースマネージャから、前記データが前記第２のリソースに前記共通鍵で暗号化された形態で一時的に格納された旨を示す通知を受信した場合に、前記第１のリソースに前記第１の形態で確定的に格納されている前記データを一時的に削除する一時的データ削除手段と、
前記トランザクションマネージャからの第２のコミット要求に応じて、前記第１のリソースから一時的に削除されている前記データを確定的に削除する確定的データ削除手段と、
前記確定的データ削除手段により前記データが確定的に削除された後に、前記第２のリソースマネージャに前記共通鍵を送信する共通鍵送信手段とを具備し、
前記第２のリソースマネージャは、
前記第１のリソースマネージャから送信された前記データを、前記第２のリソースに前記共通鍵で暗号化された形態で一時的に格納する一時的データ格納手段と、
前記トランザクションマネージャからの第１のコミット要求に応じて、前記第２のリソースに前記共通鍵で暗号化した形態で一時的に格納されている前記データを確定的に格納する確定的データ格納手段とを具備し、
前記トランザクションマネージャは、
前記第２のリソースマネージャから、コミット処理が実行可能である旨を示す通知を受信した場合に、該第２のリソースマネージャに前記第１のコミット要求を送信する第１のコミット要求送信手段と、
前記第２のリソースマネージャにおいて、前記第１のコミット要求に応じて、前記第２のリソースに前記第２の形態で一時的に格納されている前記データが、確定的に格納された後に、前記第１のリソースマネージャに前記第２のコミット要求を送信する第２のコミット要求送信手段とを具備し、
前記第１のリソースに前記第１の形態で格納されているデータと、前記第２のリソースに前記第２の形態で格納されているデータのどちらか一方のみが使用可能であることを特徴とするトランザクション処理システム。
【請求項２】
第１のリソースを管理する第１のリソースマネージャと、第２のリソースを管理する第２のリソースマネージャと、トランザクションマネージャとによって構成されるトランザクション処理システムであって、
前記第１のリソースマネージャは、
前記第１のリソースに前記第２のリソースマネージャの公開鍵で暗号化された形態で確定的に格納されているデータを、前記第２のリソースマネージャに送信するデータ送信手段と、
前記第２のリソースマネージャから、前記データが前記第２のリソースに前記公開鍵に対応する秘密鍵で復号化された形態で一時的に格納された旨を示す通知を受信した場合に、前記第１のリソースに前記公開鍵で暗号化された形態で確定的に格納されている前記データを一時的に削除する一時的データ削除手段と、
前記トランザクションマネージャからの第２のコミット要求に応じて、前記第１のリソースから一時的に削除されている前記データを確定的に削除する確定的データ削除手段とを具備し、
前記第２のリソースマネージャは、
前記第１のリソースマネージャから送信された前記データを、前記公開鍵に対応する秘密鍵で復号化された形態で、前記第２のリソースに一時的に格納する一時的データ格納手段と、
前記トランザクションマネージャからの第１のコミット要求に応じて、前記第２のリソースに前記秘密鍵で復号化された形態で一時的に格納されている前記データを確定的に格納する確定的データ格納手段とを具備し、
前記トランザクションマネージャは、
前記第２のリソースマネージャから、コミット処理が実行可能である旨を示す通知を受信した場合に、該第２のリソースマネージャに前記第１のコミット要求を送信する第１のコミット要求送信手段と、
前記第２のリソースマネージャにおいて、前記第１のコミット要求に応じて、前記第２のリソースに前記第２の形態で一時的に格納されている前記データが、確定的に格納された後に、前記第１のリソースマネージャに前記第２のコミット要求を送信する第２のコミット要求送信手段とを具備し、
前記第１のリソースに前記第１の形態で格納されているデータと、前記第２のリソースに前記第２の形態で格納されているデータのどちらか一方のみが使用可能であることを特徴とするトランザクション処理システム。
【請求項３】
第１のリソースを管理する第１のリソースマネージャと、第２のリソースを管理する第２のリソースマネージャと、トランザクションマネージャとによって構成されるトランザクション処理システムであって、
前記第１のリソースマネージャは、
前記第１のリソースに第１の形態で確定的に格納されているデータを、使用不可フラグを設定した形態で、前記第２のリソースマネージャに送信するデータ送信手段と、
前記第２のリソースマネージャから、前記データが前記第２のリソースに前記共通鍵で暗号化された形態で一時的に格納された旨を示す通知を受信した場合に、前記第１のリソースに前記第１の形態で確定的に格納されている前記データを一時的に削除する一時的データ削除手段と、
前記トランザクションマネージャからの第２のコミット要求に応じて、前記第１のリソースから一時的に削除されている前記データを確定的に削除する確定的データ削除手段と、
前記確定的データ削除手段により前記データが確定的に削除された後に、前記第１のリソースマネージャにおいて、前記第２のリソースマネージャに前記使用不可フラグの設定を解除する命令を送信する命令送信手段とを具備し、
前記第２のリソースマネージャは、
前記第１のリソースマネージャから送信された前記データを、前記第２のリソースに前記使用不可フラグを付与した形態で一時的に格納する一時的データ格納手段と、
前記トランザクションマネージャからの第１のコミット要求に応じて、前記第２のリソースに前記使用不可フラグを設定した形態で一時的に格納されている前記データを確定的に格納する確定的データ格納手段とを具備し、
前記トランザクションマネージャは、
前記第２のリソースマネージャから、コミット処理が実行可能である旨を示す通知を受信した場合に、該第２のリソースマネージャに前記第１のコミット要求を送信する第１のコミット要求送信手段と、
前記第２のリソースマネージャにおいて、前記第１のコミット要求に応じて、前記第２のリソースに前記第２の形態で一時的に格納されている前記データが、確定的に格納された後に、前記第１のリソースマネージャに前記第２のコミット要求を送信する第２のコミット要求送信手段とを具備し、
前記第１のリソースに前記第１の形態で格納されているデータと、前記第２のリソースに前記第２の形態で格納されているデータのどちらか一方のみが使用可能であることを特徴とするトランザクション処理システム。
【請求項４】
前記第２のリソースマネージャは、前記第１のリソースマネージャから前記第２のリソースマネージャへの通信時に、前記第１のリソースマネージャについての認証を行う認証手段を具備することを特徴とする請求項１乃至３のいずれか一項に記載のトランザクション処理システム。
【請求項５】
第１のリソースを管理する第１のリソースマネージャにおいて、該第１のリソースに第１の形態で確定的に格納されているデータを、共通鍵で暗号化した形態で、第２のリソースを管理する第２のリソースマネージャに送信する第１工程と、
前記第２のリソースマネージャにおいて、前記第１のリソースマネージャから送信された前記データを、前記第２のリソースに前記共通鍵で暗号化された形態で一時的に格納する第２工程と、
前記第２のリソースマネージャから、前記データが前記第２のリソースに前記共通鍵で暗号化された形態で一時的に格納された旨を示す通知を受信した場合に、前記第１のリソースマネージャにおいて、前記第１のリソースに前記第１の形態で確定的に格納されているデータを一時的に削除する第３工程と、
トランザクションマネージャにおいて、前記第２のリソースマネージャから、コミット処理が実行可能である旨を示す通知を受信した場合に、前記第２のリソースマネージャに第１のコミット要求を送信する第４工程と、
前記第２のリソースマネージャにおいて、前記第１のコミット要求に応じて、前記第２のリソースに前記共通鍵で暗号化した形態で一時的に格納されているデータを確定的に格納する第５工程と、
前記第５工程が完了した後に、前記トランザクションマネージャにおいて、前記第１のリソースマネージャに第２のコミット要求を送信する第６工程と、
前記第１のリソースマネージャにおいて、前記第２のコミット要求に応じて、前記第１のリソースから一時的に削除されているデータを確定的に削除する第７工程と、
前記第７工程において前記データが確定的に削除された後に、前記第１のリソースマネージャにおいて、前記第２のリソースマネージャに前記共通鍵を送信する工程とを有し、
前記第１のリソースに前記第１の形態で格納されているデータと、前記第２のリソースに前記第２の形態で格納されているデータのどちらか一方のみが使用可能であることを特徴とするトランザクション処理方法。
【請求項６】
第１のリソースを管理する第１のリソースマネージャにおいて、該第１のリソースに前記第２のリソースマネージャの公開鍵で暗号化された形態で確定的に格納されているデータを、第２のリソースを管理する第２のリソースマネージャに送信する第１工程と、
前記第２のリソースマネージャにおいて、前記第１のリソースマネージャから送信された前記データを、前記公開鍵に対応する秘密鍵で復号化された形態で、前記第２のリソースに第２の形態で一時的に格納する第２工程と、
前記第２のリソースマネージャから、前記データが前記第２のリソースに前記公開鍵に対応する秘密鍵で復号化された形態で一時的に格納された旨を示す通知を受信した場合に、前記第１のリソースマネージャにおいて、前記第１のリソースに前記公開鍵で暗号化された形態で確定的に格納されているデータを一時的に削除する第３工程と、
トランザクションマネージャにおいて、前記第２のリソースマネージャから、コミット処理が実行可能である旨を示す通知を受信した場合に、該前記第２のリソースマネージャに第１のコミット要求を送信する第４工程と、
前記第２のリソースマネージャにおいて、前記第１のコミット要求に応じて、前記第２のリソースに前記秘密鍵で復号化された形態で一時的に格納されているデータを確定的に格納する第５工程と、
前記第５工程が完了した後に、前記トランザクションマネージャにおいて、前記第１のリソースマネージャに第２のコミット要求を送信する第６工程と、
前記第１のリソースマネージャにおいて、前記第２のコミット要求に応じて、前記第１のリソースから一時的に削除されているデータを確定的に削除する第７工程とを有し、
前記第１のリソースに前記第１の形態で格納されているデータと、前記第２のリソースに前記第２の形態で格納されているデータのどちらか一方のみが使用可能であることを特徴とするトランザクション処理方法。
【請求項７】
第１のリソースを管理する第１のリソースマネージャにおいて、該第１のリソースに第１の形態で確定的に格納されているデータを、使用不可フラグを設定した形態で、第２のリソースを管理する第２のリソースマネージャに送信する第１工程と、
前記第２のリソースマネージャにおいて、前記第１のリソースマネージャから送信された前記データを、前記第２のリソースに前記使用不可フラグを付与した形態で一時的に格納する第２工程と、
前記第２のリソースマネージャから、前記データが前記第２のリソースに前記共通鍵で暗号化された形態で一時的に格納された旨を示す通知を受信した場合に、前記第１のリソースマネージャにおいて、前記第１のリソースに前記第１の形態で確定的に格納されているデータを一時的に削除する第３工程と、
トランザクションマネージャにおいて、前記第２のリソースマネージャから、コミット処理が実行可能である旨を示す通知を受信した場合に、前記第２のリソースマネージャに第１のコミット要求を送信する第４工程と、
前記第２のリソースマネージャにおいて、前記第１のコミット要求に応じて、前記第２のリソースに前記使用不可フラグを設定した形態で一時的に格納されているデータを確定的に格納する第５工程と、
前記第５工程が完了した後に、前記トランザクションマネージャにおいて、前記第１のリソースマネージャに第２のコミット要求を送信する第６工程と、
前記第１のリソースマネージャにおいて、前記第２のコミット要求に応じて、前記第１のリソースから一時的に削除されているデータを確定的に削除する第７工程と、
前記第７工程が完了した後に、前記第１のリソースマネージャにおいて、前記第２のリソースマネージャに前記使用不可フラグの設定を解除する命令を送信する工程とを有し、
前記第１のリソースに前記第１の形態で格納されているデータと、前記第２のリソースに前記第２の形態で格納されているデータのどちらか一方のみが使用可能であることを特徴とするトランザクション処理方法。
【請求項８】
前記第１のリソースマネージャから前記第２のリソースマネージャへの通信時に、前記第２のリソースマネージャにおいて、前記第１のリソースマネージャについての認証を行うことを特徴とする請求項５乃至７のいずれか一項に記載のトランザクション処理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、分散型データベース管理システム（ＤＢＭＳ）におけるトランザクション処理システム及びトランザクション処理方法に関する。
【０００２】
【従来の技術】
従来の分散型データベース管理システムでは、２つのリソース（データベース）を同時に更新する際に、障害の発生等の影響で、一方のリソースの更新が成功しており、他方のリソースの更新が失敗していると、同一のデータ（エンティティ）が双方のリソースに存在している状態（データの複製状態）や、特定のエンティティが双方のリソースから削除されている状態（データの紛失状態）といった、２つのリソース間におけるデータの不整合状態が生じるという問題点があった。
【０００３】
このような問題点を解決するために、通常、２つのリソースを同時に更新する際に、「２フェーズコミットメント処理」と呼ばれるトランザクション処理が用いられている。
【０００４】
図１０乃至１２を用いて「２フェーズコミットメント処理」の内容を説明する（Ｍｏｒｇａｎ  Ｋａｕｆｍａｎｎ社の“Ｐｒｉｎｃｉｐｌｅ  ｏｆ  Ｔｒａｎｓａｃｔｉｏｎ  Ｐｒｏｃｅｓｓｉｎｇ”参照）。
【０００５】
「２フェーズコミットメント処理」は、コミット処理を行う際に、トランザクション処理中にリソースの更新処理が発生した全てのリソースマネージャ１０，３０に対してコミット処理を行う準備ができているかを確認するための「プリペア要求」を発行し（第１フェーズ）、全てのリソースマネージャ１０，３０でコミット処理を行う準備ができているのであれば「コミット要求」を発行し、一つでも準備ができていない場合は「ロールバック要求」を発行する（第２フェーズ）仕組みである。
【０００６】
「２フェーズコミットメント処理」は、複数のリソースで更新処理が行われた場合に、複数のリソース間でデータの整合性を確保することを可能とするものである。また、「２フェーズコミットメント処理」は、トランザクションマネージャが、双方のリソースの更新状況を把握し、一方のリソースにおいてロールバック処理が行われた場合には、トランザクション処理全体を取り消し、データの不整合を回避することを可能とする。
【０００７】
図１０に、２フェーズコミットメント処理のフローチャートを示す。ここで、トランザクションマネージャ（ＴＭ）５０は、「２フェーズコミットメント処理」を管理するものである。また、リソースマネージャ（ＲＭ）１０，３０は、リソース（データベース）に対して更新等の操作を行う管理部の役割を果たすものである。
【０００８】
図１０は、送信側のリソースマネージャ（以下、送信側リソースマネージャ）１０により管理されているリソースから受信側のリソースマネージャ（以下、受信側リソースマネージャ）３０により管理されているリソースに、特定のエンティティ（データ）が送信され、その後、双方のリソースが更新されるケースを想定している。なお、特定のエンティティは、正常時において、１つのリソースにのみ存在するものとする。
【０００９】
図１０に示すように、ステップ１００１において、トランザクションマネージャ（ＴＭ）５０が、送信側リソースマネージャ１０に、送信側から受信側に送信すべきエンティティを識別するエンティティＩＤを含む「エンティティ送信要求」を送信する。
【００１０】
ステップ１００２において、送信側リソースマネージャ１０が、受信した「エンティティ送信要求」内のエンティティＩＤに対応するエンティティを、受信側リソースマネージャ３０に送信する。ステップ１００３において、受信側リソースマネージャ３０が、上述のエンティティを受信し、自身の管理するリソース内に記憶する。
【００１１】
ステップ１００４において、受信側リソースマネージャ３０が、「上述のエンティティを受信した旨」を示す「エンティティ受信確認（ＯＫ）」を返送する。ステップ１００５において、送信側リソースマネージャ１０が、自身の管理するリソース内から上述のエンティティを削除する。
【００１２】
ただし、この段階では、送信側リソースマネージャ１０及び受信側リソースマネージャ３０の双方において、リソース内の変更内容（上述の記憶内容及び削除内容）の確定を行わず、当該変更内容をテンポラリ領域へ格納しておく。
【００１３】
ステップ１００６において、送信側リソースマネージャ１０が、上述の「エンティティ受信確認（ＯＫ）」をトランザクションマネージャ５０に通知する。
【００１４】
ステップ１００７ａにおいて、トランザクションマネージャ５０が、送信側リソースマネージャ１０に「プリペア要求」を送信すると共に、ステップ１００７ｂにおいて、トランザクションマネージャ５０が、受信側リソースマネージャ３０に「プリペア要求」を送信する。
【００１５】
ステップ１００８ａにおいて、送信側リソースマネージャ１０が「プリペア要求」を受信してコミット処理が実行可能か否かを確認し、ステップ１００８ｂにおいて、受信側リソースマネージャ３０が「プリペア要求」を受信してコミット処理が実行可能か否かを確認する。
【００１６】
コミット処理が実行可能であると判断された場合、ステップ１００９ａにおいて、送信側リソースマネージャ１０が、トランザクションマネージャ５０に「コミット実行可能通知（ＯＫ）」を送信し、ステップ１００９ｂにおいて、受信側リソースマネージャ３０が、トランザクションマネージャ５０に「コミット実行可能通知（ＯＫ）」を送信する。そして、送信側リソースマネージャ１０及び受信側リソースマネージャ３０により管理されるリソースの各々は「セキュア状態」となる。
【００１７】
コミット処理が実行可能でないと判断された場合、送信側リソースマネージャ１０又は受信側リソースマネージャ３０が、トランザクションマネージャ５０に「コミット実行不能通知（ＮＧ）」を送信する。
【００１８】
ステップ１０１０ａにおいて、トランザクションマネージャ５０が、受信した「コミット実行可能通知（ＯＫ）」に応じて「コミット要求」を送信側リソースマネージャ１０に送信すると共に、ステップ１０１０ｂにおいて、トランザクションマネージャ５０が、受信した「コミット実行可能通知（ＯＫ）」に応じて「コミット要求」を受信側リソースマネージャ３０に送信する。
【００１９】
トランザクションマネージャ５０は、送信側リソースマネージャ１０（又は受信側リソースマネージャ３０）から、上述の「コミット実行不能通知（ＮＧ）」を受信した場合、送信側リソースマネージャ１０（又は受信側リソースマネージャ３０）に対して「ロールバック要求」を送信する。
【００２０】
ステップ１０１１ａにおいて、送信側リソースマネージャ１０が、受信した「コミット要求」に応じて、自身が管理するリソースに対してコミット処理を行い、ステップ１０１１ｂにおいて、受信側リソースマネージャ３０が、受信した「コミット要求」に応じて、自身が管理するリソースに対してコミット処理を行う。
【００２１】
ステップ１０１２ａにおいて、送信側リソースマネージャ１０が、「上述のコミット処理が完了した旨」を示す「コミット処理完了通知（ＯＫ）」をトランザクションマネージャ５０に送信し、ステップ１０１２ｂにおいて、受信側リソースマネージャ３０が、「上述のコミット処理が完了した旨」を示す「コミット処理完了通知（ＯＫ）」をトランザクションマネージャ５０に送信する。
【００２２】
上述のように、データベース１１からデータベース３１に特定のエンティティを送信し、データベース１１及びデータベース３１を更新する一連の処理を「１トランザクション処理」とする。
【００２３】
【発明が解決しようとする課題】
しかしながら、従来の「２フェーズコミットメント処理」では、「プリペア要求」送信時（すなわち、ステップ１００７ａ及び１００７ｂ時）に、障害が発生した場合やシステムが停止した場合には、双方のリソースを回復することができるが、「コミット要求」送信時（すなわち、ステップ１０１０ａ及び１０１０ｂ時）に、障害が発生した場合やシステムが停止した場合には、リソース間でデータの不整合状態が生じる可能性があるという問題点があった。
【００２４】
図１１及び図１２に、上述のデータの不整合状態が発生するケースを示す。
【００２５】
図１１は、ステップ１０１０ａにおいて障害が発生した場合、すなわち、送信側リソースマネージャ１０が、トランザクションマネージャ５０から送信された「コミット要求」を正常に受信できなかった場合の例を示す。
【００２６】
この場合、ステップ１０１１ａにおいて、送信側リソースマネージャ１０が、トランザクションマネージャ５０から送信された「ロールバック要求」に応じてロールバック処理を行う一方、ステップ１０１１ｂにおいて、受信側リソースマネージャ３０は、正常に受信した「コミット要求」に応じてコミット処理を行う。
【００２７】
したがって、送信側リソースマネージャ１０により管理されるリソースと受信側リソースマネージャ３０により管理されるリソースとの間でデータの不整合が生じる。
【００２８】
また、図１２は、ステップ１０１０ｂにおいて障害が発生した場合、すなわち、受信側リソースマネージャ３０が、トランザクションマネージャ５０から送信された「コミット要求」を正常に受信できなかった場合の例を示す。
【００２９】
この場合、ステップ１０１１ｂにおいて、受信側リソースマネージャ３０が、トランザクションマネージャ５０から送信された「ロールバック要求」に応じてロールバック処理を行う一方、ステップ１０１１ａにおいて、送信側リソースマネージャ１０は、正常に受信した「コミット要求」に応じてコミット処理を行う。
【００３０】
したがって、送信側リソースマネージャ１０により管理されるリソースと受信側リソースマネージャ３０により管理されるリソースとの間でデータの不整合が生じる。
【００３１】
かかる場合、「データの複製状態（２つのリソースに同一のデータが存在する状態）」や「データの紛失状態（２つのリソースのどちらにもデータが存在しない状態）」が生じてしまうという問題点があった。
【００３２】
そこで、本発明は、以上の点に鑑みてなされたもので、リソースの更新時に障害が発生した場合であっても、複数のリソース間でデータの不整合を回避することを目的とする。
【００３３】
【課題を解決するための手段】
本発明に係るトランザクション処理システム及びトランザクション処理方法は、第１のリソースを管理する第１のリソースマネージャが、前記第１のリソースに第１の形態で確定的に格納されているデータを、前記第２のリソースマネージャに送信するデータ送信手段と、前記第１のリソースに前記第１の形態で確定的に格納されている前記データを一時的に削除する一時的データ削除手段と、前記トランザクションマネージャからの第２のコミット要求に応じて、前記第１のリソースから一時的に削除されている前記データを確定的に削除する確定的データ削除手段とを具備し、第２のリソースを管理する第２のリソースマネージャは、前記第１のリソースマネージャから送信された前記データを、前記第２のリソースに第２の形態で一時的に格納する一時的データ格納手段と、前記トランザクションマネージャからの第１のコミット要求に応じて、前記第２のリソースに前記第２の形態で一時的に格納されている前記データを確定的に格納する確定的データ格納手段とを具備し、トランザクションマネージャが、前記第２のリソースマネージャに前記第１のコミット要求を送信する第１のコミット要求送信手段と、前記第２のリソースマネージャにおいて、前記第１のコミット要求に応じて、前記第２のリソースに前記第２の形態で一時的に格納されている前記データが、確定的に格納された後に、前記第１のリソースマネージャに前記第２のコミット要求を送信する第２のコミット要求送信手段とを具備し、前記第１のリソースに前記第１の形態で格納されているデータと、前記第２のリソースに前記第２の形態で格納されているデータのどちらか一方のみが使用可能であることを特徴とするものである。
【００３４】
かかる発明によれば、第１のリソースに第１の形態で格納されているデータと、第２のリソースに第２の形態で格納されているデータのどちらか一方のみが使用可能であり、第２のコミット要求送信手段が、第２のリソースマネージャにおいて、第２のリソースに第２の形態で一時的に格納されているデータが確定的に格納された（コミット処理が行われた）後に、前記第１のリソースマネージャに前記第２のコミット要求を送信するため、第２のリソースマネージャにおけるコミット処理完了後、第１のリソースマネージャにおけるコミット処理完了前に障害が発生した場合であっても「データの複製状態」を回避することが可能となる。
【００３５】
上述のトランザクション処理システム及びトランザクション処理方法において、前記データ送信手段が、前記第１のリソースに前記第１の形態で確定的に格納されているデータを、共通鍵で暗号化した形態で、前記第２のリソースマネージャに送信し、前記一時的データ格納手段が、前記第１のリソースマネージャから送信された前記データを、前記第２のリソースに前記共通鍵で暗号化された形態で一時的に格納し、前記確定的データ格納手段が、前記第１のコミット要求に応じて、前記第２のリソースに前記共通鍵で暗号化した形態で一時的に格納されているデータを確定的に格納し、前記第１のリソースマネージャが、前記確定的データ削除手段により前記データが確定的に削除された後に、前記第２のリソースマネージャに前記共通鍵を送信する共通鍵送信手段を具備することが好ましい。
【００３６】
かかる場合、一時的データ格納手段が、第１のリソースマネージャから共通鍵で暗号化した形態で送信されたデータを、第２のリソースに一時的に格納するため、第２のリソースマネージャにおけるコミット処理完了後、第１のリソースマネージャにおけるコミット処理完了前に障害が発生した場合に、第１のリソースに第１の形態で格納されているデータが使用可能となり、第２のリソースに第２の形態で格納されているデータが使用不可となり、「データの複製状態」を回避することが可能となる。
【００３７】
また、上述のトランザクション処理システム及びトランザクション処理方法において、前記データ送信手段が、前記第１のリソースに前記第２のリソースマネージャの公開鍵で暗号化された形態で確定的に格納されているデータを、前記第２のリソースマネージャに送信し、前記一時的データ格納手段が、前記第１のリソースマネージャから送信された前記データを、前記公開鍵に対応する秘密鍵で復号化された形態で、前記第２のリソースに一時的に格納し、前記一時的データ削除手段が、前記第１のリソースに前記公開鍵で暗号化された形態で確定的に格納されているデータを一時的に削除し、前記確定的データ格納手段が、前記第１のコミット要求に応じて、前記第２のリソースに前記秘密鍵で復号化された形態で一時的に格納されているデータを確定的に格納が好ましい。
【００３８】
かかる場合、一時的データ格納手段が、第１のリソースマネージャから送信されたデータを、第２のリソースマネージャの秘密鍵で復号化された形態で第２のリソースに一時的に格納するため、第２のリソースマネージャにおけるコミット処理完了後、第１のリソースマネージャにおけるコミット処理完了前に障害が発生した場合に、第１のリソースに第１の形態で格納されているデータが使用不可となり、第２のリソースに第２の形態で格納されているデータが使用可能となり、「データの複製状態」を回避することが可能となる。
【００３９】
また、上述のトランザクション処理システム及びトランザクション処理方法において、前記データ送信手段が、前記第１のリソースに前記第１の形態で確定的に格納されているデータを、使用不可フラグを設定した形態で、前記第２のリソースマネージャに送信し、前記一時的データ格納手段が、前記第１のリソースマネージャから送信された前記データを、前記第２のリソースに前記使用不可フラグを付与した形態で一時的に格納し、前記確定的データ格納手段が、前記第１のコミット要求に応じて、前記第２のリソースに前記使用不可フラグを設定した形態で一時的に格納されているデータを確定的に格納し、前記第１のリソースマネージャが、前記確定的データ削除手段により前記データが確定的に削除された後に、前記第１のリソースマネージャにおいて、前記第２のリソースマネージャに前記使用不可フラグの設定を解除する命令を送信する命令送信手段を具備することが好ましい。
【００４０】
かかる場合、一時的データ格納手段が、第１のリソースマネージャから使用不可フラグが設定された形態で送信されたデータを、第２のリソースに一時的に格納するため、第２のリソースマネージャにおけるコミット処理完了後、第１のリソースマネージャにおけるコミット処理完了前に障害が発生した場合に、第１のリソースに第１の形態で格納されているデータが使用可能となり、第２のリソースに第２の形態で格納されているデータが使用不可となり、「データの複製状態」を回避することが可能となる。
【００４１】
また、上述のトランザクション処理システム及びトランザクション処理方法において、前記第２のリソースマネージャが、前記第１のリソースマネージャから前記第２のリソースマネージャへの通信時に、前記第１のリソースマネージャについての認証を行う認証手段を具備することが好ましい。
【００４２】
【発明の実施の形態】
（実施形態１に係るトランザクション処理システムの構成）
本発明の実施形態１に係るトランザクション処理システムの構成について図を参照しながら説明する。図１は、本実施形態に係るトランザクション処理システムの概要構成を示す図である。
【００４３】
本実施形態に係るトランザクション処理システムは、送信側リソースマネージャ１０が管理するリソース（データベース）１１内のデータ（エンティティ）を、受信側リソースマネージャ３０が管理するリソース（データベース）３１に送信する際に、データベース１１及びデータベース３１の更新時に障害が発生した場合であっても、データベース１１とデータベース３１との間におけるデータの不整合（「データの複製状態」及び「データの紛失状態」）を回避するように機能するものである。
【００４４】
本実施形態に係るトランザクション処理システムは、図１に示すように、送信側リソースマネージャ１０と、受信側リソースマネージャ３０と、トランザクションマネージャ５０とによって構成されている。
【００４５】
本実施形態において、送信側リソースマネージャ１０及び受信側リソースマネージャ３０の各構成要素（後述）は、耐タンパ装置に格納されているため、トランザクション処理の流れの中で決められた操作以外の操作や外部からの不正な操作はできないものとする。また、データベース１１及びデータベース３１の双方に、同時に使用可能な同一のエンティティが存在しなければ「データの複製状態」を回避したものとする。
【００４６】
以下、送信側リソースマネージャ１０、受信側リソースマネージャ３０及びトランザクションマネージャ５０の構成要素のうち、本発明に関連するものについて説明する。
【００４７】
送信側リソースマネージャ１０は、図１に示すように、データベース（ＤＢ）１１と、共通鍵生成部１２と、暗号化部１３と、リソースマネージャインタフェース（Ｉ/Ｆ）部１４と、トランザクションマネージャインタフェース（Ｉ/Ｆ）部１５とを具備している。
【００４８】
本実施形態において、データベース１１が、第１のリソースを構成する。
【００４９】
また、リソースマネージャＩ/Ｆ部１４が、第１のリソース（データベース１１）に第１の形態で確定的に格納されているデータ（エンティティ）を、第２のリソースマネージャ（受信側リソースマネージャ３０）に送信するデータ送信手段を構成する。
【００５０】
また、リソースマネージャＩ/Ｆ部１４が、第１のリソース（データベース１１）に第１の形態で確定的に格納されているデータ（エンティティ）を一時的に削除する一時的データ削除手段を構成する。
【００５１】
また、トランザクションマネージャＩ/Ｆ部１５が、トランザクションマネージャ５０からの第２のコミット要求に応じて、第１のリソース（データベース１１）から一時的に削除されているデータ（エンティティ）を確定的に削除する確定的データ削除手段を構成する。
【００５２】
また、共通鍵生成部１２及びリソースマネージャＩ/Ｆ部１４が、確定的データ削除手段によりデータが確定的に削除された後に、第２のリソースマネージャ（受信側リソースマネージャ３０）に共通鍵を送信する共通鍵送信手段を構成する。
【００５３】
本明細書において、「確定的に」と表現される状態は、コミット処理が行われている確定的な状態を示し、「一時的に」と表現される状態は、ロールバック処理によって直近のコミット処理後の状態に戻り得る一時的な状態を示す。
【００５４】
データベース１１は、暗号化部１３とリソースマネージャＩ/Ｆ部１４とトランザクションマネージャＩ/Ｆ部１５とに接続されており、データ（エンティティ）を格納している第１のリソースである。
【００５５】
共通鍵生成部１２は、暗号化部１３とリソースマネージャＩ/Ｆ部１４とに接続されており、暗号化部１３からの指示に応じて共通鍵を生成し、生成した共通鍵を暗号化部１３に送信するものである。
【００５６】
また、共通鍵生成部１２は、リソースマネージャＩ/Ｆ部１４から要求された共通鍵をリソースマネージャＩ/Ｆ部１４に送信する。また、共通鍵生成部１２は、上述の共通鍵を、当該トランザクション処理に関連付けて記憶する。
【００５７】
暗号化部１３は、データベース１１と共通鍵生成部１２とリソースマネージャＩ/Ｆ部１４とトランザクションマネージャＩ/Ｆ部１５とに接続されており、トランザクションマネージャＩ/Ｆ部１５から「エンティティ送信要求」を受信した場合に、当該「エンティティ送信要求」内のエンティティＩＤに対応するエンティティをデータベース１１から抽出すると共に、共通鍵生成部１２に共通鍵の生成を指示する。
【００５８】
また、暗号化部１３は、抽出したエンティティを共通鍵生成部１３から送信された共通鍵を用いて暗号化し、暗号化したエンティティ（以下、暗号化エンティティ）をリソースマネージャＩ/Ｆ部１４に送信する。
【００５９】
リソースマネージャＩ/Ｆ部１４は、データベース１１と共通鍵生成部１２と暗号化部１３とトランザクションマネージャＩ/Ｆ部１５とに接続されており、受信側リソースマネージャ３０との間のインタフェースの役割を果たすものである。
【００６０】
具体的には、リソースマネージャＩ/Ｆ部１４は、「送信側リソースマネージャ１０の認証情報」を、受信側リソースマネージャ３０に送信する。また、リソースマネージャＩ/Ｆ部１４は、受信側リソースマネージャ３０からの肯定的な認証結果（ＯＫ）を受信した場合、暗号化部１３から送信された暗号化エンティティを、受信側リソースマネージャ３０に送信する。
【００６１】
また、リソースマネージャＩ/Ｆ部１４は、受信側リソースマネージャ３０から送信された「エンティティ受信確認（ＯＫ）」を受信した場合に、データベース１１内の該当するエンティティを一時的に削除する処理を行うと共に、「エンティティ受信確認（ＯＫ）」をトランザクションマネージャＩ/Ｆ部１５に通知する。
【００６２】
また、リソースマネージャＩ/Ｆ部１４は、トランザクションマネージャＩ/Ｆ部１５からの「コミット処理完了通知（ＯＫ）」に応じて、当該トランザクション処理に関連付けられた共通鍵の送信を共通鍵生成部１２に要求する。
【００６３】
そして、リソースマネージャＩ/Ｆ部１４は、共通鍵生成部１２から送信された共通鍵を「送信側リソースマネージャ１０の認証情報」と共に、受信側リソースマネージャ３０に送信する。
【００６４】
また、リソースマネージャＩ/Ｆ部１４は、受信側リソースマネージャ３０から「復号化完了通知（ＯＫ）」を受信した場合、該当する共通鍵を共通鍵生成部１２から削除する。
【００６５】
トランザクションマネージャＩ/Ｆ部１５は、データベース１１と暗号化部１３とリソースマネージャＩ/Ｆ部１４とに接続されており、トランザクションマネージャ５０との間のインタフェースの役割を果たすものである。
【００６６】
具体的には、トランザクションマネージャＩ/Ｆ部１５は、トランザクションマネージャ５０から送信された「エンティティ送信要求」を暗号化部１３に送信する。また、トランザクションマネージャＩ/Ｆ部１５は、リソースマネージャＩ/Ｆ部１４から送信された「エンティティ受信確認（ＯＫ）」をトランザクションマネージャ５０に通知する。
【００６７】
また、トランザクションマネージャＩ/Ｆ部１５は、トランザクションマネージャ５０から送信された「プリペア要求」に応じて、データベース１１に対してコミット処理が実行可能か否かを確認する。トランザクションマネージャＩ/Ｆ部１５は、上述のコミット処理が実行可能であると判断した場合、トランザクションマネージャ５０に「コミット実行可能通知（ＯＫ）」を送信し、上述のコミット処理が実行可能でないと判断した場合、トランザクションマネージャ５０に「コミット実行不能通知（ＮＧ）」を送信する。
【００６８】
また、トランザクションマネージャＩ/Ｆ部１５は、トランザクションマネージャ５０から送信された「コミット要求」に応じて、データベース１１に対してコミット処理を行い（すなわち、データベース１１から一時的に削除されているデータを確定的に削除し）、トランザクションマネージャ５０から送信された「ロールバック要求」に応じて、データベース１１に対してロールバック処理を行う（すなわち、データベース１１から一時的に削除されているデータを回復させる）。
【００６９】
また、トランザクションマネージャＩ/Ｆ部１５は、上述のコミット処理が完了した場合「コミット処理完了通知（ＯＫ）」をトランザクションマネージャ５０に送信し、上述のコミット処理が失敗した場合「コミット処理失敗通知（ＮＧ）」をトランザクションマネージャ５０に送信する。
【００７０】
また、トランザクションマネージャＩ/Ｆ部１５は、「コミット処理完了通知（ＯＫ）」をトランザクションマネージャ５０に通知した後「コミット処理完了通知（ＯＫ）」をリソースマネージャＩ/Ｆ部１４に通知する。
【００７１】
受信側リソースマネージャ３０は、図１に示すように、データベース（ＤＢ）３１と、リソースマネージャインタフェース（Ｉ/Ｆ）部３２と、トランザクションマネージャインタフェース（Ｉ/Ｆ）部３３と、復号化部３４とを具備している。
【００７２】
本実施形態において、データベース３１が、第２のリソースを構成する。
【００７３】
また、リソースマネージャＩ/Ｆ部３２が、第１のリソースマネージャ（送信側リソースマネージャ１０）から送信されたデータ（エンティティ）を、第２のリソース（データベース３１）に、第２の形態で（共通鍵で暗号化された形態で）一時的に格納する一時的データ格納手段を構成する。
【００７４】
また、トランザクションマネージャＩ/Ｆ部３３が、トランザクションマネージャ５０からの第１のコミット要求に応じて、第２のリソース（データベース３１）に、第２の形態で（共通鍵で暗号化された形態で）一時的に格納されているデータ（エンティティ）を確定的に格納する確定的データ格納手段を構成する。
【００７５】
データベース３１は、リソースマネージャＩ/Ｆ部３２とトランザクションマネージャＩ/Ｆ部３３と復号化部３４とに接続されており、データ（エンティティ）を格納している第２のリソースである。
【００７６】
リソースマネージャＩ/Ｆ部３２は、データベース３１と復号化部３４とに接続されており、送信側リソースマネージャ１０との間のインタフェースの役割を果たすものである。
【００７７】
具体的には、リソースマネージャＩ/Ｆ部３２は、送信側リソースマネージャ１０から送信された「送信側リソースマネージャ１０の認証情報」に基づいて認証を行い、その認証結果を送信側リソースマネージャ１０に返送する。そして、リソースマネージャＩ/Ｆ部３２は、当該「送信側リソースマネージャ１０の認証情報」を、当該トランザクション処理に関連付けて記憶する。
【００７８】
また、上述の認証結果が肯定的（ＯＫ）であった場合、リソースマネージャＩ/Ｆ部３２は、送信側リソースマネージャ１０から送信された「暗号化エンティティ」を受信し、受信した「暗号化エンティティ」を当該トランザクション処理に関連付けてデータベース３１に一時的に格納する。リソースマネージャＩ/Ｆ部３２は、上述の格納が成功した場合「エンティティ受信確認（ＯＫ）」を送信側リソースマネージャ１０に返送する。
【００７９】
また、リソースマネージャＩ/Ｆ部３２は、送信側リソースマネージャ１０から送信された「送信側リソースマネージャ１０の識別情報」に基づく認証結果が肯定的（ＯＫ）である場合、当該「送信側リソースマネージャ１０の識別情報」と共に送信された共通鍵を復号化部３４に転送する。
【００８０】
また、リソースマネージャＩ/Ｆ部３２は、復号化部３４による暗号化エンティティの復号化が完了した場合「復号化完了通知（ＯＫ）」を送信側リソースマネージャ１０に返送し、当該トランザクション処理に関連付けられた「送信側リソースマネージャ１０の識別情報」を削除する。
【００８１】
トランザクションマネージャＩ/Ｆ部３３は、データベース３１に接続されており、トランザクションマネージャ５０との間のインタフェースの役割を果たすものである。
【００８２】
具体的には、トランザクションマネージャＩ/Ｆ部３３は、トランザクションマネージャ５０から送信された「プリペア要求」に応じて、データベース３１に対してコミット処理が実行可能か否かを確認する。トランザクションマネージャＩ/Ｆ部３３は、上述のコミット処理が実行可能であると判断した場合、トランザクションマネージャ５０に「コミット実行可能通知（ＯＫ）」を送信し、上述のコミット処理が実行可能でないと判断した場合、トランザクションマネージャ５０に「コミット実行不能通知（ＮＧ）」を送信する。
【００８３】
また、トランザクションマネージャＩ/Ｆ部３３は、トランザクションマネージャ５０から送信された「コミット要求」に応じて、データベース３１に対してコミット処理を行い（すなわち、データベース３１に一時的に格納されているデータを確定的に格納し）、トランザクションマネージャ５０から送信された「ロールバック要求」に応じて、データベース３１に対してロールバック処理を行う（すなわち、データベース３１に一時的に格納されているデータを確定的に削除する）。
【００８４】
また、トランザクションマネージャＩ/Ｆ部３３は、上述のコミット処理が完了した場合「コミット処理完了通知（ＯＫ）」をトランザクションマネージャ５０に送信し、上述のコミット処理が失敗した場合「コミット処理失敗通知（ＮＧ）」をトランザクションマネージャ５０に送信する。
【００８５】
復号化部３４は、データベース３１とリソースマネージャＩ/Ｆ部３２とに接続されており、リソースマネージャＩ/Ｆ部３２から転送された共通鍵を用いて、データベース３１内の該当する暗号化エンティティを復号化するものである。
【００８６】
トランザクションマネージャ５０は、図１に示すように、エンティティ送信要求管理部５１と、プリペア要求管理部５２と、コミット要求管理部５３とを具備している。
【００８７】
本実施形態において、コミット要求管理部５３が、第２のリソースマネージャ（受信側リソースマネージャ３０）に第１のコミット要求を送信する第１のコミット要求送信手段を構成する。
【００８８】
また、コミット要求管理部５３が、第２のリソースマネージャ（受信側リソースマネージャ３０）において、第１のコミット要求に応じて、第２のリソース（データベース３１）に第２の形態で（共通鍵で暗号化された状態で）一時的に格納されているデータ（エンティティ）が、確定的に格納された後に、第１のリソースマネージャ（送信側リソースマネージャ１０）に第２のコミット要求を送信する第２のコミット要求送信手段を構成する。
【００８９】
エンティティ送信要求管理部５１は、プリペア要求管理部５２に接続されており、送信側リソースマネージャ１０に「エンティティ送信要求」を送信する。「エンティティ送信要求」は、送信側から受信側に送信すべきエンティティの識別情報（エンティティＩＤ）と、受信側リソースマネージャ３０の識別情報を含む。
【００９０】
また、エンティティ送信要求管理部５１は、送信側リソースマネージャ１０から送信された「エンティティ受信確認（ＯＫ）」をプリペア要求管理部５２に通知する。
【００９１】
プリペア要求管理部５２は、エンティティ送信要求管理部５１とコミット要求管理部５３とに接続されており、エンティティ送信要求管理部５１から通知された「エンティティ受信確認（ＯＫ）」に応じて「プリペア要求」を、送信側リソースマネージャ１０及び受信側リソースマネージャ３０の双方に送信する。
【００９２】
また、プリペア要求管理部５２は、送信側リソースマネージャ１０及び受信側リソースマネージャ３０から送信された「コミット実行可能通知（ＯＫ）」及び「コミット実行不能通知（ＮＧ）」をコミット要求管理部５３に通知する。
【００９３】
コミット要求管理部５３は、プリペア要求管理部５２に接続されており、プリペア要求管理部５２から送信された「コミット実行可能通知（ＯＫ）」に応じて、最初に受信側リソースマネージャ３０に「コミット要求」を送信する。その後、コミット要求管理部５３は、受信側リソースマネージャ３０から「コミット処理完了通知（ＯＫ）」を受信した場合、送信側リソースマネージャ１０に「コミット要求」を送信する。
【００９４】
また、コミット要求管理部５３は、プリペア要求管理部５２から送信された「コミット実行不能通知（ＮＧ）」に応じて「ロールバック要求」を、送信側リソースマネージャ１０（又は、受信側リソースマネージャ３０）に送信する。
【００９５】
また、コミット要求管理部５３は、送信側リソースマネージャ１０（又は、受信側リソースマネージャ３０）から「コミット処理失敗通知（ＮＧ）」を受信した場合、及び、所定期間内に送信側リソースマネージャ１０（又は、受信側リソースマネージャ３０）から「コミット処理完了通知（ＯＫ）」を受信しなかった場合、「ロールバック要求」を送信側リソースマネージャ１０（又は、受信側リソースマネージャ３０）に送信する。
【００９６】
（実施形態１に係るトランザクション処理システムの動作）
実施形態１に係るトランザクション処理システムの動作について、図２を参照にして説明する。図２は、特定のエンティティが、送信側リソースマネージャ１０から受信側リソースマネージャ３０に送信される際に、本実施形態に係るトランザクション処理システムにより行われるトランザクション処理を示すタイムチャート図である。
【００９７】
図２に示すように、ステップ２０１において、トランザクションマネージャ５０のエンティティ送信要求管理部５１が、送信側リソースマネージャ１０に、送信側から受信側に送信すべきエンティティを識別するエンティティＩＤを含む「エンティティ送信要求」を送信する。送信側リソースマネージャ１０のトランザクションマネージャＩ/Ｆ部１５が、上述の「エンティティ送信要求」を受信する。
【００９８】
ステップ２０２において、トランザクションマネージャＩ/Ｆ部１５が、上述の「エンティティ送信要求」を暗号化部１３に送信する。ステップ２０３において、暗号化部１３が、当該「エンティティ送信要求」内のエンティティＩＤに対応するエンティティをデータベース１１から抽出すると共に、共通鍵生成部１２に共通鍵の生成を指示する。そして、暗号化部１３は、抽出したエンティティを共通鍵生成部１３から送信された共通鍵を用いて暗号化し、暗号化エンティティをリソースマネージャＩ/Ｆ部１４に送信する。
【００９９】
ステップ２０４において、リソースマネージャＩ/Ｆ部１４が、「送信側リソースマネージャ１０の認証情報」を受信側リソースマネージャ３０に送信する。そして、受信側リソースマネージャ３０から送信された「送信側リソースマネージャ１０の認証情報」に基づく認証結果が、肯定的（ＯＫ）である場合、リソースマネージャＩ/Ｆ部１４が、上述の暗号化エンティティを受信側リソースマネージャ３０に送信する。
【０１００】
ここで、受信側リソースマネージャ３０のリソースマネージャＩ/Ｆ部３２が、「送信側リソースマネージャ１０の認証情報」を当該トランザクション処理に関連付けて記憶する。
【０１０１】
ステップ２０５において、受信側リソースマネージャ３０のリソースマネージャＩ/Ｆ部３２が、上述の暗号化エンティティを受信し、上述の暗号化エンティティを当該トランザクション処理に関連付けてデータベース３１内に記憶する。ただし、ロールバック処理を可能とするために、この段階では、データベース３１内で上述の記憶内容の確定を行わず、上述の記憶内容をテンポラリ領域へ格納しておく。
【０１０２】
ステップ２０６において、リソースマネージャＩ/Ｆ部３２が、「上述の暗号化エンティティを受信した旨」を示す「エンティティ受信確認（ＯＫ）」を送信側リソースマネージャ１０に返送する。
【０１０３】
ステップ２０７において、リソースマネージャＩ/Ｆ部１４が、受信した「エンティティ受信確認（ＯＫ）」に応じて、データベース１１内の該当するエンティティを削除する処理を行うと共に、「エンティティ受信確認（ＯＫ）」をトランザクションマネージャＩ/Ｆ部１５に通知する。ただし、ロールバック処理を可能とするために、この段階では、データベース１１内で上述の削除内容の確定を行わず、上述の削除内容をテンポラリ領域へ格納しておく。
【０１０４】
ステップ２０８において、トランザクションマネージャＩ/Ｆ部１５が、通知された「エンティティ受信確認（ＯＫ）」をトランザクションマネージャ５０に送信する。そして、トランザクションマネージャ５０のエンティティ送信要求管理部５１が、受信した「エンティティ受信確認（ＯＫ）」をプリペア要求管理部５２に送信する。
【０１０５】
ステップ２０９ａにおいて、プリペア要求管理部５２が、受信した「エンティティ受信確認（ＯＫ）」に応じて、送信側リソースマネージャ１０に「プリペア要求」を送信すると共に、ステップ２０９ｂにおいて、プリペア要求管理部５２が、受信した「エンティティ受信確認（ＯＫ）」に応じて、受信側リソースマネージャ３０に「プリペア要求」を送信する。
【０１０６】
ステップ２１０ａにおいて、送信側リソースマネージャ１０のトランザクションマネージャＩ/Ｆ部１５が「プリペア要求」を受信してデータベース１１に対してコミット処理が実行可能か否かを確認し、ステップ２１０ｂにおいて、受信側リソースマネージャ３０のトランザクションマネージャＩ/Ｆ部３３が「プリペア要求」を受信してデータベース３１に対してコミット処理が実行可能か否かを確認する。
【０１０７】
コミット処理が実行可能であると判断された場合、ステップ２１１ａにおいて、トランザクションマネージャＩ/Ｆ部１５が、トランザクションマネージャ５０に「コミット実行可能通知（ＯＫ）」を送信し、ステップ２１１ｂにおいて、トランザクションマネージャＩ/Ｆ部３３が、トランザクションマネージャ５０に「コミット実行可能通知（ＯＫ）」を送信する。そして、データベース１１及びデータベース３１の各々は「セキュア状態」となる。
【０１０８】
ステップ２１２において、コミット要求管理部５３が、プリペア要求管理部５２を介して受信した「コミット実行可能通知（ＯＫ）」に応じて「コミット要求」を受信側リソースマネージャ３０に送信する。
【０１０９】
ステップ２１３において、トランザクションマネージャＩ/Ｆ部３３が、トランザクションマネージャ５０から送信された「コミット要求」に応じて、データベース３１に対してコミット処理を行う。
【０１１０】
ステップ２１４において、トランザクションマネージャＩ/Ｆ部３３が、上述のコミット処理が完了した旨を示す「コミット処理完了通知（ＯＫ）」をトランザクションマネージャ５０に送信する。
【０１１１】
ステップ２１５において、コミット要求管理部５３が、受信側リソースマネージャ３０から受信した「コミット実行可能通知（ＯＫ）」に応じて「コミット要求」を送信側リソースマネージャ１０に送信する。
【０１１２】
ステップ２１６において、トランザクションマネージャＩ/Ｆ部１５が、トランザクションマネージャ５０から送信された「コミット要求」に応じて、データベース１１に対してコミット処理を行う。
【０１１３】
ステップ２１７において、トランザクションマネージャＩ/Ｆ部１５が、上述のコミット処理が完了した旨を示す「コミット処理完了通知（ＯＫ）」をトランザクションマネージャ５０に送信する。そして、トランザクションマネージャＩ/Ｆ部１５が、「コミット処理完了通知（ＯＫ）」をトランザクションマネージャ５０に通知した後「コミット処理完了通知（ＯＫ）」をリソースマネージャＩ/Ｆ部１４に通知する。
【０１１４】
ステップ２１８において、リソースマネージャＩ/Ｆ部１４が、トランザクションマネージャＩ/Ｆ部１５からの「コミット処理完了通知（ＯＫ）」に応じて、当該トランザクション処理に関連付けられた共通鍵の送信を共通鍵生成部１２に要求する。そして、リソースマネージャＩ/Ｆ部１４が、共通鍵生成部１２から送信された共通鍵を「送信側リソースマネージャ１０の識別情報」と共に、受信側リソースマネージャ３０に送信する。
【０１１５】
ステップ２１９において、リソースマネージャＩ/Ｆ部３２が、送信側リソースマネージャ１０から送信された「送信側リソースマネージャ１０の識別情報」に基づく認証結果が肯定的（ＯＫ）である場合、上述の共通鍵を復号化部３４に転送する。
【０１１６】
ステップ２２０において、復号化部３４が、リソースマネージャＩ/Ｆ部３２から転送された共通鍵を用いて、当該トランザクション処理に関連付けられたデータベース３１内の暗号化エンティティを復号化する。
【０１１７】
ステップ２２１において、リソースマネージャＩ/Ｆ部３２が、復号化部３４による暗号化エンティティの復号化が完了した旨を示す「復号化完了通知（ＯＫ）」を送信側リソースマネージャ１０に返送する。また、リソースマネージャＩ/Ｆ部３２が、当該トランザクション処理に関連付けられた「送信側リソースマネージャ１０の識別情報」を削除する。
【０１１８】
ステップ２２２において、リソースマネージャＩ/Ｆ部１４が、受信側リソースマネージャ３０から受信した「復号化完了通知（ＯＫ）」に応じて、当該トランザクション処理に関連付けられた共通鍵を共通鍵生成部１２から削除する。
【０１１９】
ステップ２１８及びステップ２２１は、一般的な通信プロトコルを用いて実現されるため、当該通信プロトコルによる再送及び再接続が行われる。
【０１２０】
図３に、本実施形態に係るトランザクション処理システムにより上述のトランザクション処理が行われる場合のデータベース１１及びデータベース３１の状態を示す。
【０１２１】
図３に示すように、ステップ２１７終了時、すなわち、送信側リソースマネージャ１０においてコミット処理が正常に終了した際、送信側リソースマネージャ１０のデータベース１１には、当該トランザクション処理に関連するエンティティは記憶されておらず（削除されており）、受信側リソースマネージャ３０のデータベース３１には、当該トランザクション処理に関連する「暗号化エンティティ」が記憶されている（第１の状態）。
【０１２２】
また、ステップ２１３終了前、すなわち、受信側リソースマネージャ３０においてコミット処理が正常に終了する前に障害が発生したケースでは、送信側リソースマネージャ１０のデータベース１１には、当該トランザクション処理に関連する「エンティティ」が記憶されており、受信側リソースマネージャ３０のデータベース３１には、当該トランザクション処理に関連するエンティティは記憶されていない（第２の状態）。この場合、データベース１１及びデータベース３１の双方に対してロールバック処理が行われている。
【０１２３】
また、ステップ２１３終了後でステップ２１６終了前、すなわち、受信側リソースマネージャ３０においてコミット処理が正常に終了した後で送信側リソースマネージャ１０においてコミット処理が正常に終了する前に障害が発生したケースでは、送信側リソースマネージャ１０のデータベース１１には、当該トランザクション処理に関連する「エンティティ」が記憶されており、受信側リソースマネージャ３０のデータベース３１には、当該トランザクション処理に関連する「暗号化エンティティ」が記憶されている（第３の状態）。この場合、データベース１１に対してのみロールバック処理が行われている。
【０１２４】
したがって、上述の第１乃至第３の状態のいずれにおいても、データベース１１及びデータベース３１の双方に、同時に使用可能な同一のエンティティが存在しないため、「データの複製状態」を回避することが可能である。
【０１２５】
ここで、「使用可能」とは、データベース１１，３１内に、利用可能な状態（例えば、暗号化されていない状態や、使用不可フラグが設定されていない状態等）で格納されていることを示す。
【０１２６】
したがって、第３の状態では、データベース１１に「エンティティ」が存在し、データベース３１に「暗号化エンティティ」が存在しているが、受信側リソースマネージャ３０（復号化部３４）が当該暗号化エンティティを復号化するための共通鍵を有していないため、データベース３１内の当該暗号化エンティティは使用可能ではないと考える。
【０１２７】
（実施形態１に係るトランザクション処理システムの作用・効果）
本実施形態に係るトランザクション処理システムによれば、受信側リソースマネージャ３０のリソースマネージャＩ/Ｆ部３２が、送信側リソースマネージャ１０から共通鍵で暗号化した形態で送信されたエンティティを、データベース３１に一時的に格納するため、受信側リソースマネージャ３０におけるコミット処理完了後、送信側リソースマネージャ１０におけるコミット処理完了前に障害が発生した場合に、データベース１１に第１の形態で格納されているエンティティが使用可能となり、データベース３１に共通鍵で暗号化した形態で格納されているエンティティが使用不可となり、「データの複製状態」を回避することが可能となる。
【０１２８】
（実施形態２に係るトランザクション処理システムの構成）
本発明の実施形態２に係るトランザクション処理システムの構成について図を参照しながら説明する。図４は、本実施形態に係るトランザクション処理システムの概要構成を示す図である。
【０１２９】
以下、本発明の実施形態２に係るトランザクション処理システムの構成について、上述の実施形態１に係るトランザクション処理システムの構成と異なる点についてのみ説明する。
【０１３０】
送信側リソースマネージャ１０の構成は、図４に示すように、実施形態１に係る送信側リソースマネージャ１０が具備している共通鍵生成部１２を具備していない点を除いて、実施形態１に係る送信側リソースマネージャ１０と同一の構成である。また、受信側リソースマネージャ３０の構成は、図４に示すように、実施形態１に係る受信側リソースマネージャ３０の構成に加えて、鍵管理部３５を具備している。トランザクションマネージャ５０は、実施形態１に係るトランザクションマネージャ５０と同一の構成である。
【０１３１】
上述の鍵管理部３５は、リソースマネージャＩ/Ｆ部３２とトランザクションマネージャＩ/Ｆ部３３と復号化部３４とに接続されており、トランザクションマネージャＩ/Ｆ部３３を介してトランザクションマネージャ５０から送信された「エンティティ送信要求」に応じて、リソースマネージャＩ/Ｆ部３２に「受信側リソースマネージャ３０の公開鍵」を送信する。また、鍵管理部３５は、復号化部３４からの要求に応じて「受信側リソースマネージャ３０の秘密鍵」を復号化部３４に送信する。
【０１３２】
（実施形態２に係るトランザクション処理システムの動作）
実施形態２に係るトランザクション処理システムの動作について、図５を参照にして説明する。図５は、特定のエンティティが、送信側リソースマネージャ１０から受信側リソースマネージャ３０に送信される際に、本実施形態に係るトランザクション処理システムにより行われるトランザクション処理を示すタイムチャート図である。
【０１３３】
図５に示すように、ステップ５０１において、トランザクションマネージャ５０のエンティティ送信要求管理部５１が、送信側リソースマネージャ１０に、送信側から受信側に送信すべきエンティティを識別するエンティティＩＤを含む「エンティティ送信要求」を送信する。送信側リソースマネージャ１０のトランザクションマネージャＩ/Ｆ部１５が、上述の「エンティティ送信要求」を受信する。
【０１３４】
また、ステップ５０２において、トランザクションマネージャ５０のエンティティ送信要求管理部５１が、受信側リソースマネージャ３０に、上述の「エンティティ送信要求」を送信する。受信側リソースマネージャ３０のトランザクションマネージャＩ/Ｆ部３３が、上述の「エンティティ送信要求」を受信する。
【０１３５】
ステップ５０３において、トランザクションマネージャＩ/Ｆ部３３が、上述の「エンティティ送信要求」を鍵管理部３５に送信する。そして、リソースマネージャＩ/Ｆ部３２が、上述の「エンティティ送信要求」に応じて鍵管理部３５から送信された「受信側リソースマネージャ３０の公開鍵」を、送信側リソースマネージャ１０に送信する。
【０１３６】
ステップ５０４において、暗号化部１３が、上述の「エンティティ送信要求」内のエンティティＩＤに対応するデータベース１１内のエンティティを、受信側リソースマネージャ３０から送信された「受信側リソースマネージャ３０の公開鍵」を用いて暗号化する。
【０１３７】
そして、暗号化部１３が、データベース１１内から「暗号化エンティティ」を抽出し、抽出した「暗号化エンティティ」をリソースマネージャＩ/Ｆ部１４に送信する。
【０１３８】
ステップ５０５において、リソースマネージャＩ/Ｆ部１４が、「送信側リソースマネージャ１０の認証情報」を受信側リソースマネージャ３０に送信する。そして、受信側リソースマネージャ３０から送信された「送信側リソースマネージャ１０の認証情報」に基づく認証結果が、肯定的（ＯＫ）である場合、上述の「暗号化エンティティ」を受信側リソースマネージャ３０に送信する。
【０１３９】
ここで、受信側リソースマネージャ３０のリソースマネージャＩ/Ｆ部３２が、「送信側リソースマネージャ１０の認証情報」を当該トランザクション処理に関連付けて記憶する。
【０１４０】
ステップ５０６において、受信側リソースマネージャ３０のリソースマネージャＩ/Ｆ部３２が、上述の「暗号化エンティティ」を受信し、上述の「暗号化エンティティ」を当該トランザクション処理に関連付けてデータベース３１内に一時的に記憶する。ただし、ロールバック処理を可能とするために、この段階では、データベース３１内で上述の記憶内容の確定を行わず、上述の記憶内容をテンポラリ領域へ格納しておく。
【０１４１】
ステップ５０７において、復号化部３４が、鍵管理部３５から送信された「受信側リソースマネージャ３０の秘密鍵」を用いて、上述の「暗号化エンティティ」を復号化する。
【０１４２】
ステップ５０８において、リソースマネージャＩ/Ｆ部３２が、「上述の暗号化エンティティを受信した旨」を示す「エンティティ受信確認（ＯＫ）」を送信側リソースマネージャ１０に返送する。
【０１４３】
ステップ５０９において、リソースマネージャＩ/Ｆ部１４が、受信した「エンティティ受信確認（ＯＫ）」に応じて、データベース１１内の該当する「暗号化エンティティ」を一時的に削除する処理を行うと共に、「エンティティ受信確認（ＯＫ）」をトランザクションマネージャＩ/Ｆ部１５に通知する。ただし、ロールバック処理を可能とするために、この段階では、データベース１１内で上述の削除内容の確定を行わず、上述の削除内容をテンポラリ領域へ格納しておく。
【０１４４】
ステップ５１０において、トランザクションマネージャＩ/Ｆ部１５が、通知された「エンティティ受信確認（ＯＫ）」をトランザクションマネージャ５０に送信する。そして、トランザクションマネージャ５０のエンティティ送信要求管理部５１が、受信した「エンティティ受信確認（ＯＫ）」をプリペア要求管理部５２に送信する。
【０１４５】
ステップ５１１ａにおいて、プリペア要求管理部５２が、受信した「エンティティ受信確認（ＯＫ）」に応じて、送信側リソースマネージャ１０に「プリペア要求」を送信すると共に、ステップ５１１ｂにおいて、プリペア要求管理部５２が、受信した「エンティティ受信確認（ＯＫ）」に応じて、受信側リソースマネージャ３０に「プリペア要求」を送信する。
【０１４６】
ステップ５１２ａにおいて、送信側リソースマネージャ１０のトランザクションマネージャＩ/Ｆ部１５が「プリペア要求」を受信してデータベース１１に対してコミット処理が実行可能か否かを確認し、ステップ５１２ｂにおいて、受信側リソースマネージャ３０のトランザクションマネージャＩ/Ｆ部３３が「プリペア要求」を受信してデータベース３１に対してコミット処理が実行可能か否かを確認する。
【０１４７】
コミット処理が実行可能であると判断された場合、ステップ５１３ａにおいて、トランザクションマネージャＩ/Ｆ部１５が、トランザクションマネージャ５０に「コミット実行可能通知（ＯＫ）」を送信し、ステップ５１３ｂにおいて、トランザクションマネージャＩ/Ｆ部３３が、トランザクションマネージャ５０に「コミット実行可能通知（ＯＫ）」を送信する。そして、データベース１１及びデータベース３１の各々は「セキュア状態」となる。
【０１４８】
ステップ５１４において、コミット要求管理部５３が、プリペア要求管理部５２を介して受信した「コミット実行可能通知（ＯＫ）」に応じて「コミット要求」を受信側リソースマネージャ３０に送信する。
【０１４９】
ステップ５１５において、トランザクションマネージャＩ/Ｆ部３３が、トランザクションマネージャ５０から送信された「コミット要求」に応じて、データベース３１に対してコミット処理を行う。
【０１５０】
ステップ５１６において、トランザクションマネージャＩ/Ｆ部３３が、上述のコミット処理が完了した旨を示す「コミット処理完了通知（ＯＫ）」をトランザクションマネージャ５０に送信する。
【０１５１】
ステップ５１７において、コミット要求管理部５３が、受信側リソースマネージャ３０から受信した「コミット実行可能通知（ＯＫ）」に応じて「コミット要求」を送信側リソースマネージャ１０に送信する。
【０１５２】
ステップ５１８において、トランザクションマネージャＩ/Ｆ部１５が、トランザクションマネージャ５０から送信された「コミット要求」に応じて、データベース１１に対してコミット処理を行う。
【０１５３】
ステップ５１９において、トランザクションマネージャＩ/Ｆ部１５が、上述のコミット処理が完了した旨を示す「コミット処理完了通知（ＯＫ）」をトランザクションマネージャ５０に送信する。
【０１５４】
その後、リソースマネージャＩ/Ｆ部３２が、当該トランザクション処理に関連付けられた「送信側リソースマネージャ１０の識別情報」を削除する。
【０１５５】
図６に、本実施形態に係るトランザクション処理システムにより上述のトランザクション処理が行われる場合のデータベース１１及びデータベース３１の状態を示す。
【０１５６】
図６に示すように、ステップ５１９終了時、すなわち、送信側リソースマネージャ１０においてコミット処理が正常に終了した際、送信側リソースマネージャ１０のデータベース１１には、当該トランザクション処理に関連するエンティティは記憶されておらず（削除されており）、受信側リソースマネージャ３０のデータベース３１には、当該トランザクション処理に関連するエンティティが記憶されている（第１の状態）。
【０１５７】
また、ステップ５１５終了前、すなわち、受信側リソースマネージャ３０においてコミット処理が正常に終了する前に障害が発生したケースでは、送信側リソースマネージャ１０のデータベース１１には、当該トランザクション処理に関連する暗号化エンティティが記憶されており、受信側リソースマネージャ３０のデータベース３１には、当該トランザクション処理に関連するエンティティは記憶されていない（第２の状態）。この場合、データベース１１及びデータベース３１の双方に対してロールバック処理が行われている。
【０１５８】
また、ステップ５１５終了後でステップ５１８終了前、すなわち、受信側リソースマネージャ３０においてコミット処理が正常に終了した後で送信側リソースマネージャ１０においてコミット処理が正常に終了する前に障害が発生したケースでは、送信側リソースマネージャ１０のデータベース１１には、当該トランザクション処理に関連する暗号化エンティティが記憶されており、受信側リソースマネージャ３０のデータベース３１には、当該トランザクション処理に関連するエンティティが記憶されている（第３の状態）。この場合、データベース１１に対してのみロールバック処理が行われている。
【０１５９】
したがって、上述の第１乃至第３の状態のいずれにおいても、データベース１１及びデータベース３１の双方に、同時に使用可能な同一のエンティティが存在しないため、「データの複製状態」を回避することが可能である。
【０１６０】
ここで、第３の状態では、データベース１１に「暗号化エンティティ」が存在し、データベース３１に「エンティティ」が存在しているが、送信側リソースマネージャ１０が当該暗号化エンティティを復号化するための「受信側リソースマネージャ３０の秘密鍵」を有していないため、データベース１１内の当該暗号化エンティティは使用可能ではないと考える。
【０１６１】
（実施形態２に係るトランザクション処理システムの作用・効果）
本実施形態に係るトランザクション処理システムによれば、受信側リソースマネージャ３０のリソースマネージャＩ/Ｆ部３２が、送信側リソースマネージャ１０から送信されたエンティティを、受信側リソースマネージャ３０の秘密鍵で復号化された形態でデータベース３１に一時的に格納するため、受信側リソースマネージャ３０におけるコミット処理完了後、送信側リソースマネージャ１０におけるコミット処理完了前に障害が発生した場合に、データベース１１に第１の形態で（受信側リソースマネージャ３０の公開鍵で暗号化された形態で）格納されているエンティティが使用不可となり、データベース３１に第２の形態で（受信側リソースマネージャ３０の秘密鍵で復号化された形態で）格納されているエンティティが使用可能となり、「データの複製状態」を回避することが可能となる。
【０１６２】
（実施形態３に係るトランザクション処理システムの構成）
本発明の実施形態３に係るトランザクション処理システムの構成について図を参照しながら説明する。図７は、本実施形態に係るトランザクション処理システムの概要構成を示す図である。
【０１６３】
以下、本発明の実施形態３に係るトランザクション処理システムの構成について、上述の実施形態１に係るトランザクション処理システムの構成と異なる点についてのみ説明する。
【０１６４】
送信側リソースマネージャ１０の構成は、図７に示すように、実施形態１に係る送信側リソースマネージャ１０が具備している共通鍵生成部１２及び暗号化部１３の代わりに、フラグ管理部１６を具備している。また、受信側リソースマネージャ３０の構成は、図７に示すように、実施形態１に係る受信側リソースマネージャ３０が具備している復号化部３４の代わりに、フラグ管理部３６を具備している。トランザクションマネージャ５０は、実施形態１に係るトランザクションマネージャ５０と同一の構成である。
【０１６５】
上述のフラグ管理部１６は、データベース１１とリソースマネージャＩ/Ｆ部１４とトランザクションマネージャＩ/Ｆ部１５とに接続されており、トランザクションマネージャＩ/Ｆ部１５から「エンティティ送信要求」を受信した場合に、当該「エンティティ送信要求」内のエンティティＩＤに対応するエンティティをデータベース１１から抽出し、抽出したエンティティ内のフラグを「使用不可」とする（すなわち、抽出したエンティティに「使用不可」フラグを設定する）。そして、フラグ管理部１６は、「使用不可」フラグが設定された形態のエンティティ（以下、フラグ付エンティティ）をリソースマネージャＩ/Ｆ部１４に送信する。
【０１６６】
上述のフラグ管理部３６は、データベース３１とリソースマネージャＩ/Ｆ部３２とに接続されており、送信側リソースマネージャ１０からリソースマネージャＩ/Ｆ部３２を介して、「使用不可」フラグの設置を解除するに命令が送信された場合、データベース３１内の該当する「フラグ付エンティティ」の「使用不可」フラグの設定を解除する。
【０１６７】
（実施形態３に係るトランザクション処理システムの動作）
実施形態３に係るトランザクション処理システムの動作について、図８を参照にして説明する。図８は、特定のエンティティが、送信側リソースマネージャ１０から受信側リソースマネージャ３０に送信される際に、本実施形態に係るトランザクション処理システムにより行われるトランザクション処理を示すタイムチャート図である。
【０１６８】
図８に示すように、ステップ８０１において、トランザクションマネージャ５０のエンティティ送信要求管理部５１が、送信側リソースマネージャ１０に、送信側から受信側に送信すべきエンティティを識別するエンティティＩＤを含む「エンティティ送信要求」を送信する。送信側リソースマネージャ１０のトランザクションマネージャＩ/Ｆ部１５が、上述の「エンティティ送信要求」を受信する。
【０１６９】
ステップ８０２において、トランザクションマネージャＩ/Ｆ部１５が、上述の「エンティティ送信要求」をフラグ管理部１６に送信する。そして、フラグ管理部１６が、当該「エンティティ送信要求」内のエンティティＩＤに対応するエンティティをデータベース１１から抽出し、抽出したエンティティの「使用不可」フラグを設定する。そして、フラグ管理部１６は、このフラグ付エンティティをリソースマネージャＩ/Ｆ部１４に送信する。
【０１７０】
ステップ８０３において、リソースマネージャＩ/Ｆ部１４が、「送信側リソースマネージャ１０の認証情報」を受信側リソースマネージャ３０に送信する。そして、受信側リソースマネージャ３０から送信された「送信側リソースマネージャ１０の認証情報」に基づく認証結果が、肯定的（ＯＫ）である場合、リソースマネージャＩ/Ｆ部１４が、上述のフラグ付エンティティを受信側リソースマネージャ３０に送信する。
【０１７１】
ここで、受信側リソースマネージャ３０のリソースマネージャＩ/Ｆ部３２が、「送信側リソースマネージャ１０の認証情報」を当該トランザクション処理に関連付けて記憶する。
【０１７２】
ステップ８０４において、受信側リソースマネージャ３０のリソースマネージャＩ/Ｆ部３２が、上述のフラグ付エンティティを受信し、上述のフラグ付エンティティを当該トランザクション処理に関連付けてデータベース３１内に一時的に記憶する。ただし、ロールバック処理を可能とするために、この段階では、データベース３１内で上述の記憶内容の確定を行わず、上述の記憶内容をテンポラリ領域へ格納しておく。
【０１７３】
ステップ８０５において、リソースマネージャＩ/Ｆ部３２が、「上述のフラグ付エンティティを受信した旨」を示す「エンティティ受信確認（ＯＫ）」を送信側リソースマネージャ１０に返送する。
【０１７４】
ステップ８０６において、リソースマネージャＩ/Ｆ部１４が、受信した「エンティティ受信確認（ＯＫ）」に応じて、データベース１１内の該当するエンティティを一時的に削除する処理を行うと共に、「エンティティ受信確認（ＯＫ）」をトランザクションマネージャＩ/Ｆ部１５に通知する。ただし、ロールバック処理を可能とするために、この段階では、データベース１１内で上述の削除内容の確定を行わず、上述の削除内容をテンポラリ領域へ格納しておく。
【０１７５】
ステップ８０７において、トランザクションマネージャＩ/Ｆ部１５が、通知された「エンティティ受信確認（ＯＫ）」をトランザクションマネージャ５０に送信する。そして、トランザクションマネージャ５０のエンティティ送信要求管理部５１が、受信した「エンティティ受信確認（ＯＫ）」をプリペア要求管理部５２に送信する。
【０１７６】
ステップ８０８ａにおいて、プリペア要求管理部５２が、受信した「エンティティ受信確認（ＯＫ）」に応じて、送信側リソースマネージャ１０に「プリペア要求」を送信すると共に、ステップ８０８ｂにおいて、プリペア要求管理部５２が、受信した「エンティティ受信確認（ＯＫ）」に応じて、受信側リソースマネージャ３０に「プリペア要求」を送信する。
【０１７７】
ステップ８０９ａにおいて、送信側リソースマネージャ１０のトランザクションマネージャＩ/Ｆ部１５が「プリペア要求」を受信してデータベース１１に対してコミット処理が実行可能か否かを確認し、ステップ８０９ｂにおいて、受信側リソースマネージャ３０のトランザクションマネージャＩ/Ｆ部３３が「プリペア要求」を受信してデータベース３１に対してコミット処理が実行可能か否かを確認する。
【０１７８】
コミット処理が実行可能であると判断された場合、ステップ８１０ａにおいて、トランザクションマネージャＩ/Ｆ部１５が、トランザクションマネージャ５０に「コミット実行可能通知（ＯＫ）」を送信し、ステップ８１０ｂにおいて、トランザクションマネージャＩ/Ｆ部３３が、トランザクションマネージャ５０に「コミット実行可能通知（ＯＫ）」を送信する。そして、データベース１１及びデータベース３１の各々は「セキュア状態」となる。
【０１７９】
ステップ８１１において、コミット要求管理部５３が、プリペア要求管理部５２を介して受信した「コミット実行可能通知（ＯＫ）」に応じて「コミット要求」を受信側リソースマネージャ３０に送信する。
【０１８０】
ステップ８１２において、トランザクションマネージャＩ/Ｆ部３３が、トランザクションマネージャ５０から送信された「コミット要求」に応じて、データベース３１に対してコミット処理を行う。
【０１８１】
ステップ８１３において、トランザクションマネージャＩ/Ｆ部３３が、上述のコミット処理が完了した旨を示す「コミット処理完了通知（ＯＫ）」をトランザクションマネージャ５０に送信する。
【０１８２】
ステップ８１４において、コミット要求管理部５３が、受信側リソースマネージャ３０から受信した「コミット実行可能通知（ＯＫ）」に応じて「コミット要求」を送信側リソースマネージャ１０に送信する。
【０１８３】
ステップ８１５において、トランザクションマネージャＩ/Ｆ部１５が、トランザクションマネージャ５０から送信された「コミット要求」に応じて、データベース１１に対してコミット処理を行う。
【０１８４】
ステップ８１６において、トランザクションマネージャＩ/Ｆ部１５が、上述のコミット処理が完了した旨を示す「コミット処理完了通知（ＯＫ）」をトランザクションマネージャ５０に送信する。そして、トランザクションマネージャＩ/Ｆ部１５が、「コミット処理完了通知（ＯＫ）」をトランザクションマネージャ５０に通知した後「コミット処理完了通知（ＯＫ）」をリソースマネージャＩ/Ｆ部１４に通知する。
【０１８５】
ステップ８１７において、リソースマネージャＩ/Ｆ部１４が、トランザクションマネージャＩ/Ｆ部１５からの「コミット処理完了通知（ＯＫ）」に応じて、当該トランザクション処理に関連付けられたフラグ付エンティティの「使用不可」フラグの設定を解除する命令と共に、「送信側リソースマネージャ１０の識別情報」を、受信側リソースマネージャ３０に送信する。
【０１８６】
ステップ８１８において、リソースマネージャＩ/Ｆ部３２が、送信側リソースマネージャ１０から送信された「送信側リソースマネージャ１０の識別情報」に基づく認証結果が肯定的（ＯＫ）である場合、上述の命令をフラグ管理部３６に通知する。そして、フラグ管理部３６が、当該トランザクション処理に関連付けられたデータベース３１内のフラグ付エンティティの「使用不可」フラグの設定を解除する。
【０１８７】
ステップ８１９において、リソースマネージャＩ/Ｆ部３２が、フラグ管理部３６による上述の処理（「使用不可」フラグの設定を解除する処理）が完了した旨を示す「設定解除完了通知（ＯＫ）」を送信側リソースマネージャ１０に返送する。また、リソースマネージャＩ/Ｆ部３２が、当該トランザクション処理に関連付けられた「送信側リソースマネージャ１０の識別情報」を削除する。
【０１８８】
図９に、本実施形態に係るトランザクション処理システムにより上述のトランザクション処理が行われる場合のデータベース１１及びデータベース３１の状態を示す。
【０１８９】
図９に示すように、ステップ８１６終了時、すなわち、送信側リソースマネージャ１０においてコミット処理が正常に終了した際、送信側リソースマネージャ１０のデータベース１１には、当該トランザクション処理に関連するエンティティは記憶されておらず（削除されている）、受信側リソースマネージャ３０のデータベース３１には、当該トランザクション処理に関連するフラグ付エンティティが記憶されている（第１の状態）。この場合、データベース１１及びデータベース３１の双方に対してロールバック処理が行われている。
【０１９０】
また、ステップ８１２終了前、すなわち、受信側リソースマネージャ３０においてコミット処理が正常に終了する前に障害が発生したケースでは、送信側リソースマネージャ１０のデータベース１１には、当該トランザクション処理に関連するエンティティが記憶されており、受信側リソースマネージャ３０のデータベース３１には、当該トランザクション処理に関連するエンティティは記憶されていない（第２の状態）。
【０１９１】
また、ステップ８１２終了後でステップ８１５終了前、すなわち、受信側リソースマネージャ３０においてコミット処理が正常に終了した後で送信側リソースマネージャ１０においてコミット処理が正常に終了する前に障害が発生したケースでは、送信側リソースマネージャ１０のデータベース１１には、当該トランザクション処理に関連するエンティティが記憶されており、受信側リソースマネージャ３０のデータベース３１には、当該トランザクション処理に関連するフラグ付エンティティが記憶されている（第３の状態）。この場合、データベース１１に対してのみロールバック処理が行われている。
【０１９２】
したがって、上述の第１乃至第３の状態のいずれにおいても、データベース１１及びデータベース３１の双方に、同時に使用可能な同一のエンティティが存在しないため、「データの複製状態」を回避することが可能である。
【０１９３】
ここで、第３の状態では、データベース１１に「エンティティ」が存在し、データベース３１に「フラグ付エンティティ」が存在しているが、「フラグ付エンティティ」はフラグを「使用可能」としない限り使用可能にはならない。
【０１９４】
（実施形態３に係るトランザクション処理システムの作用・効果）
実施形態３に係るトランザクション処理システムによれば、受信側リソースマネージャ３０のリソースマネージャＩ/Ｆ部３２が、送信側リソースマネージャ１０から使用不可フラグが設定された形態で送信されたエンティティを、データベース３１に一時的に格納するため、受信側リソースマネージャ３０におけるコミット処理完了後、送信側リソースマネージャにおけるコミット処理完了前に障害が発生した場合に、データベース１１に第１の形態で格納されているエンティティが使用可能となり、データベース３１に第２の形態で（使用不可フラグが設定された形態で）格納されているエンティティが使用不可となり、「データの複製状態」を回避することが可能となる。
【０１９５】
また、実施形態３に係るトランザクション処理システムによれば、受信側リソースマネージャ３０のリソースマネージャＩ/Ｆ部３２が、送信側リソースマネージャ１０から受信側リソースマネージャ３０への通信時に、送信側リソースマネージャ１０についての認証を行うため、第三者により比較的簡単に偽造可能である「使用不可」フラグの設定を解除する命令に対する信頼性を高めることが可能となる。
【０１９６】
【発明の効果】
以上説明したように本発明によれば、データベース１１，３１の更新時に障害が発生した場合であっても、複数のデータベース１１，３１間でデータの不整合を回避することを目的とする。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るトランザクション処理システムの概略構成図である。
【図２】本発明の一実施形態に係るトランザクション処理システムの動作を示すタイムチャート図である。
【図３】本発明の一実施形態に係るトランザクション処理システムの動作におけるデータベース内に格納されているデータを示す図である。
【図４】本発明の一実施形態に係るトランザクション処理システムの概略構成図である。
【図５】本発明の一実施形態に係るトランザクション処理システムの動作を示すタイムチャート図である。
【図６】本発明の一実施形態に係るトランザクション処理システムの動作におけるデータベース内に格納されているデータを示す図である。
【図７】本発明の一実施形態に係るトランザクション処理システムの概略構成図である。
【図８】本発明の一実施形態に係るトランザクション処理システムの動作を示すタイムチャート図である。
【図９】本発明の一実施形態に係るトランザクション処理システムの動作におけるデータベース内に格納されているデータを示す図である。
【図１０】従来技術に係る２フェーズコミットメント処理を示すタイムチャート図である。
【図１１】従来技術に係る２フェーズコミットメント処理において、データの不整合が発生する例を示すタイムチャート図である。
【図１２】従来技術に係る２フェーズコミットメント処理において、データの不整合が発生する例を示すタイムチャート図である。
【符号の説明】
１０…送信側リソースマネージャ
１１、３１…データベース（ＤＢ）
１２…共通鍵生成部
１３…暗号化部
１４、３２…リソースマネージャインタフェース（Ｉ/Ｆ）部
１５、３３…トランザクションマネージャインタフェース（Ｉ/Ｆ）部
１６、３６…フラグ管理部
３０…受信側リソースマネージャ
３４…復号化部
３５…鍵管理部
５０…トランザクションマネージャ
５１…エンティティ送信要求管理部
５２…プリペア要求管理部
５３…コミット要求管理部
【図１】
0004180816.tif 000002
【図２】
0004180816.tif 000003
【図３】
0004180816.tif 000004
【図４】
0004180816.tif 000005
【図５】
0004180816.tif 000006
【図６】
0004180816.tif 000007
【図７】
0004180816.tif 000008
【図８】
0004180816.tif 000009
【図９】
0004180816.tif 000010
【図１０】
0004180816.tif 000011
【図１１】
0004180816.tif 000012
【図１２】
0004180816.tif 000013