JP2014164311A - トランザクション処理装置、トランザクション処理システム、トランザクション処理方法及びプログラム - Google Patents

Abstract

【課題】クライアントアプリケーションおよびサーバアプリケーションに改造を行うことなくトランザクション処理の未処理および重複処理を回避することが出来るトランザクション処理装置を提供すること。
【解決手段】本発明にかかるトランザクション処理装置２は、トランザクションデータを保持するメッセージキュー管理部１１と、トランザクション処理を実行するトランザクション処理部２１と、を備える。メッセージキュー管理部１１は、トランザクションデータをトランザクション処理部２１へ出力した回数を示す再送回数をトランザクションデータと対応付けて管理し、トランザクション処理部２１は、メッセージキュー管理部１１からトランザクションデータとともに再送回数に関する情報を併せて取得し、再送回数に関する情報に再送が行われていないことを示す値が設定されている場合、トランザクション処理を実行するものである。
【選択図】図１

Description

本発明はトランザクション処理装置、トランザクション処理システム、トランザクション処理方法及びプログラムに関し、特にトランザクションデータを保持するキューを有するトランザクション処理装置、トランザクション処理システム、トランザクション処理方法及びプログラムに関する。

非同期メッセージキュー内のトランザクションデータを用いてリソースを更新する方法として、２相コミットを利用する方法がある。しかし、２相コミットは、性能劣化が生じるという問題がある。さらには、更新先リソースが１相コミット・リソース（２相コミットに対応してない）の場合には、この方法が適用できないという問題がある。

１相コミット・リソースを更新対象とする場合に、トランザクション処理プログラムがキューからトランザクションデータを取得して１相コミット・リソースの更新処理の完了後、キューからのトランザクションデータの削除前に障害が発生したとする。この時、トランザクション処理プログラムは、キューからトランザクションデータを再度取得しリソースを再度更新してしまうことがありえる。一方、リソースの再更新を避けるために、トランザクション処理プログラムがキューからトランザクションデータを取得後、リソースの更新前にキューからトランザクションデータを削除することが考えられる。しかし、リソースの更新前にトランザクション処理プログラムに障害が発生するとトランザクションデータが消失しリソースが未処理となる。

すなわち、非同期メッセージキュー内のトランザクションデータを用いて１相コミット・リソースを更新するトランザクション処理プログラムにおいて、トランザクションデータの消失を防ぎ、かつ、２重処理を防ぐことは技術的に困難とされていた。

このような背景において、特許文献１では次のような解決策が提示されている。すなわち、トランザクション処理プログラムは、各トランザクションデータに一意のデータIDを付与する。さらに、業務システムは、更新先リソースと同じデータベース上に処理済みのデータIDを格納するIDテーブルを設ける。これにより、トランザクション処理プログラムは、トランザクションデータの処理前にIDテーブル中に該当のデータIDが存在するかを確認し、存在しなければ未処理のデータであると判断して処理を行い、存在する場合は重複（つまり処理済み）のデータであるとして２重処理を回避する、という方法も考えられている。

特開２００１−３０６３８０号公報

しかし、特許文献１に開示されている方法には、更新先リソースがデータベースであることを前提とし、IDテーブルを同じデータベース内に作成することによって本来更新したいリソース（一般に業務テーブル）とＩＤテーブルの更新の確定を同時に行えることを前提とする制約がある、という問題点があった。

また、データIDやIDテーブルは、２重処理を回避するためだけに用いられる。そのため、トランザクションデータを生成するクライアントアプリケーションもしくはトランザクションデータを処理するサーバアプリケーションが通常扱う対象の情報ではない。しかし、特許文献１に開示されている方法においては、クライアントアプリケーションによるデータIDの付与やサーバアプリケーションによる管理テーブルからのデータIDの参照・検証が必要である。このように、特許文献１における業務システムは、本来の業務アプリケーション（すなわちクライアントアプリケーションとサーバアプリケーション）と２重処理回避の機構とが分離できない構成であるため、業務アプリケーションの開発者がデータID付与やIDテーブルを利用する２重処理回避の機能を実装する必要がある、という問題点がある。同様の理由から、既に存在している業務アプリケーションにこの方法を適用するには、クライアントアプリケーションやサーバアプリケーションの改造が必要になる、という問題点もあった。

本発明の目的は、上述した課題のいずれかを解決するトランザクション処理装置、トランザクション処理システム、トランザクション処理方法及びプログラムを提供することにある。

本発明の第１の態様にかかるトランザクション処理装置は、入力されたトランザクションデータを保持するメッセージキュー管理部と、前記トランザクションデータを用いてトランザクション処理を実行するトランザクション処理部と、を備え、前記メッセージキュー管理部は、前記トランザクションデータを前記トランザクション処理部へ出力した回数を示す再送回数を前記トランザクションデータと対応付けて管理し、前記トランザクション処理部は、前記メッセージキュー管理部から前記トランザクションデータとともに前記再送回数に関する情報を併せて取得し、前記再送回数に関する情報に再送が行われていないことを示す値が設定されている場合、前記トランザクション処理を実行するものである。

本発明の第２の態様にかかるトランザクション処理システムは、トランザクションデータを出力するクライアントアプリケーションと、前記出力されたトランザクションデータを保持するメッセージキュー管理部と、前記トランザクションデータを用いてトランザクション処理を実行するトランザクション処理部と、を有するトランザクション処理装置と、前記トランザクション処理が実行されることにより更新されるリソースを保持するデータ格納装置と、を備えるトランザクション処理システムであって、前記メッセージキュー管理部は、前記トランザクションデータを前記トランザクション処理部へ出力した回数を示す再送回数を前記トランザクションデータと対応付けて管理し、前記トランザクション処理部は、前記メッセージキュー管理部から前記トランザクションデータとともに前記再送回数に関する情報を併せて取得し、前記再送回数に関する情報に再送が行われていないことを示す値が設定されている場合、前記トランザクション処理を実行するものである。

本発明の第３の態様にかかるトランザクション処理方法は、入力されたトランザクションデータを保持し、前記トランザクションデータを用いてトランザクション処理を実行するトランザクション処理部へ、前記トランザクションデータを出力した回数を示す再送回数を前記トランザクションデータに設定し、前記再送回数に関する情報に再送が行われていないことを示す値が設定されている場合、前記トランザクションデータを用いて前記トランザクション処理を実行するものである。

本発明の第４の態様にかかるプログラムは、入力されたトランザクションデータを保持するステップと、前記トランザクションデータを用いてトランザクション処理を実行するトランザクション処理部へ、前記トランザクションデータを出力した回数を示す再送回数を前記トランザクションデータに設定するステップと、前記再送回数に関する情報に再送が行われていないことを示す値が設定されている場合、前記トランザクションデータを用いて前記トランザクション処理を実行するステップと、をコンピュータに実行させるものである。

本発明により、クライアントアプリケーションおよびサーバアプリケーションに改造を行うことなくトランザクション処理の重複処理を回避することが出来るトランザクション処理装置、トランザクション処理システム、トランザクション処理方法及びプログラムを提供することが出来る。

実施の形態１にかかるトランザクション処理装置の構成図である。 実施の形態２にかかるトランザクション処理装置の構成図である。 実施の形態２にかかる管理テーブルの構成図である。 実施の形態２にかかるトランザクション処理装置における処理の流れを示す図である。 実施の形態２にかかるケース１〜４において実行処理を判定する際の条件及び処理の実行内容を示す図である。 実施の形態２にかかるトランザクション判断プログラムにおける判断ロジックを説明する図である。 実施の形態２にかかるトランザクションデータ受信時のキュー入出力管理部の動作を示す図である。 実施の形態２にかかるトランザクションデータ送信時のキュー入出力管理部の動作を示す図である。 実施の形態２にかかるトランザクションデータ削除時のキュー入出力管理部の動作を示す図である。 実施の形態３にかかるトランザクション処理装置の構成図である。 実施の形態４にかかるトランザクション処理装置の構成図である。 実施の形態４にかかる管理テーブルの構成図である。 実施の形態４にかかるトランザクション処理装置における処理の流れを示す図である。 実施の形態４にかかるトランザクション処理装置における処理の流れを示す図である。

（実施の形態１）
以下、図面を参照して本発明の実施の形態について説明する。図１を用いて本発明の実施の形態１にかかるトランザクション処理装置２の構成例について説明する。トランザクション処理装置２は、メッセージキュー管理部１１及びトランザクション処理部２１を有している。

メッセージキュー管理部１１は、入力されたトランザクションデータを保持する。さらに、メッセージキュー管理部１１は、入力されたトランザクションデータと、このトランザクションデータをトランザクション処理部２１へ出力した回数を示す再送回数とを対応付けて管理する。メッセージキュー管理部１１は、トランザクション処理部２１からトランザクションデータの出力指示を受けると、トランザクションデータをトランザクション処理部２１へ出力する。また、トランザクション処理部２１は、受け取ったトランザクションデータを用いて正常にトランザクション処理を完了することが出来なかった場合、再度同じトランザクションデータの出力を指示する場合がある。このような場合に、メッセージキュー管理部１１は、トランザクションデータを再送する。

トランザクション処理部２１は、メッセージキュー管理部１１から出力されたトランザクションデータを用いてトランザクション処理を実行する。トランザクション処理は、例えば、トランザクションデータを用いてリソースを更新する処理等であってもよい。トランザクション処理部２１は、メッセージキュー管理部１１からトランザクションデータを取得するとともに、トランザクションデータの再送回数に関する情報も併せて取得する。ここで、トランザクション処理部２１は、トランザクションデータの再送回数に関する情報に、過去に再送が行われていないことを示す値が設定されている場合、例えば、再送回数が０回であるとの値が設定されている場合、トランザクション処理を実行する。

以上説明したように、図１のトランザクション処理装置２を用いることにより、トランザクションデータを出力するクライアントアプリケーション等において、重複したトランザクション処理を回避するためにのみ用いられるトランザクションデータのID等を付与する必要がなくなる。つまり、トランザクション処理装置２は、ID等が付与されていないトランザクションデータを受け取り、トランザクション処理装置２内におけるトランザクションデータの再送回数を管理する。これより、トランザクションデータを出力するクライアントアプリケーション等は、トランザクション処理装置２内における重複したトランザクション処理の回避に用いられる情報を付与する必要がなく、トランザクション処理の回避のために新たな機能追加等を行う必要がない。

（実施の形態２）
続いて、図２を用いて本発明の実施の形態２にかかるトランザクション処理装置２の構成例について主に説明する。図２において、図１と同様の機能を有する構成要素には、図１と同様の符号を付して説明する。トランザクション処理装置２は、クライアントアプリケーション１及びリソース３と通信を行う。

クライアントアプリケーション１は、トランザクション処理装置２にトランザクションデータを投入するアプリケーションである。

リソース３は、トランザクション処理装置２が更新の対象とするリソースである。リソース３は、例えば、ファイルシステム上のファイルが考えられるが、トランザクション処理装置２の制御外のアプリケーションに対してリソース更新を意味する要求を送信することも考えられる（ＨＴＴＰのＰＯＳＴメソッドなど）。リソース３は、メモリ等のデータ格納装置に格納されるデータであってもよい。

トランザクション処理装置２は、メッセージキュー管理部１１及びトランザクション処理部２１を有している。さらにメッセージキュー管理部１１は、メッセージキュー１２、キュー入出力管理部１６、再送回数管理部１７及びトランザクションデータＩＤ発行部１９を有している。

キュー入出力管理部１６は、クライアントアプリケーション１から出力されたトランザクションデータ１８を受け取る。トランザクションデータＩＤ発行部１９は、受信したトランザクションデータ１８に対して、一意のトランザクションデータＩＤ１４を払い出す。メッセージキュー１２は、キュー入出力管理部１６において受け取ったトランザクションデータ１８を格納する。再送回数管理部１７は、トランザクション処理部２１に対するトランザクションデータ１８の送信回数（再送回数）を管理する。

トランザクションデータ１８は、トランザクションデータＩＤ１４及び再送回数情報が関連付けられてメッセージキュー１２に格納される。

続いて、トランザクション処理部２１の構成例について説明する。トランザクション処理部２１は、キュー監視部２２、トランザクションデータＩＤ管理部２５、トランザクション判断プログラム登録部２６及びサーバアプリケーション２３を有している。

キュー監視部２２は、メッセージキュー１２に格納されたトランザクションデータ１８を取得するための送信要求もしくはメッセージキュー１２に格納されたトランザクションデータ１８を削除するための確認応答をキュー入出力管理部１６へ送信する。

トランザクションデータＩＤ管理部２５は、キュー監視部２２において取得したトランザクションデータに関する情報を格納する。トランザクション判断プログラム登録部２６は、トランザクションを実行するか否かを規定したトランザクション判断プログラム２７を登録する。トランザクション判断プログラム２７については、後に詳述する。サーバアプリケーション２３は、トランザクションデータ１８を用いてリソース３を更新する。

トランザクションデータＩＤ管理部２５は、管理テーブル２４を有する。ここで、図３を用いて管理テーブル２４の構成例を示す。管理テーブル２４には、各トランザクションデータＩＤの状態が「実行中」もしくは「完了」として登録されている。なお、管理テーブル２４内の項目（カラム）は、後述するトランザクション判断プログラム２７の判断に利用できるように適宜増やしてもしてもよい。例えば、トランザクションデータの項目には、各トランザクションデータが、データの種別としてテストデータであることが示されている。再送回数の項目には、各トランザクションデータをトランザクション処理部２１へ再送した回数が示されている。受信時刻の項目には、トランザクション処理部２１が、各トランザクションデータをメッセージキュー管理部１１から取得した時刻が示されている。

ここで、トランザクション処理装置２の利用者（一般にアプリケーション開発者）は、サーバアプリケーション２３とトランザクション判断プログラム２７をトランザクション処理装置２に実装する。さらに、トランザクション処理装置２の利用者は、クライアントアプリケーションも開発する。

サーバアプリケーション２３は、１相コミット・リソースを更新するプログラムである。サーバアプリケーション２３は、ファイルシステム上のファイルを更新するプログラムである場合や、トランザクション処理装置２とネットワークを介して接続された外部のトランザクション処理装置内のトランザクション処理プログラムを呼び出すプログラムである場合であってもよい。いずれの場合も、リソース３は、２相コミットに対応していないため、リソース３の更新とメッセージキュー１２の更新（トランザクションデータ１８の削除）とは、同一のトランザクション内で実行されない。なお、クライアントアプリケーション１とサーバアプリケーション２３とをあわせて業務アプリケーションと定義してもよい。

トランザクション判断プログラム２７は、リソース３の更新処理が完了しているかをトランザクションデータＩＤ管理部２５内の管理テーブル２４から判断できない場合に、キュー監視部２２において利用されるプログラムである。トランザクション判断プログラム２７は、トランザクションデータＩＤを入力パラメータに持ち、当該トランザクションデータＩＤのトランザクションが実行完了したことを意味する「重複」か、実行失敗ことを意味する「新規」を出力する。どのようなルールに基づいて判断するかはアプリケーション開発者が決定してもよい。トランザクション判断プログラム２７は、管理テーブル２４内に格納された再送回数もしくは受信時刻等を利用してもよく、トランザクション処理装置のログ情報を利用してもよい。トランザクション判断プログラム２７の具体例については、後述する。

続いて、図４を用いてトランザクション処理装置２における処理の流れについて説明する。

はじめに、トランザクション処理部２１内のキュー監視部２２は、キュー入出力管理部１６経由でメッセージキュー１２を監視する。キュー監視部２２は、メッセージキュー１２にトランザクションデータ１８が格納されていることを検出した場合、トランザクションデータ１８を取得する。その際、キュー監視部２２は、トランザクションデータ１８の他に、トランザクションデータ１８に付随するトランザクションデータＩＤ１４と再送回数に関する情報（再送回数情報）とも併せて取得する（ステップＡ０１）。

次に、キュー監視部２２は、再送回数情報を確認する（ステップＡ０２）。キュー監視部２２は、再送回数情報が「再送回数＝０」の場合、メッセージキュー１２から取得したトランザクションデータ１８を処理すべきデータとみなす。この場合、キュー監視部２２は、トランザクションデータＩＤ管理部２５内の管理テーブル２４にトランザクションデータ１８のレコードを新規登録する。キュー監視部２２は、トランザクションデータ１８を登録する際に「ステータス（状態）＝実行中」として登録する（ステップＡ０５）。次に、サーバアプリケーション２３は、トランザクション処理を実行する（ステップＡ１０）。トランザクション処理の実行後、キュー監視部２２は、管理テーブル２４内の該当トランザクションデータＩＤ１４のレコードを「ステータス＝完了」へ更新する（ステップＡ１１）。最後に、キュー監視部２２は、確認応答をキュー入出力管理部１６へ出力する（ステップＡ１２）。後述するが、キュー入出力管理部１６は、確認応答を受信すると該当するトランザクションデータ１８をメッセージキュー１２から削除する。ステップＡ０２において、キュー監視部２２が、再送回数＝０であることを確認した以降の処理の流れをケース１とする。

ステップＡ０２において、キュー監視部２２は、再送回数が１以上の場合、トランザクションデータＩＤ管理部２５中の管理テーブル２４からステップＡ０１で取得したトランザクションデータＩＤ１４と一致するレコードを検索する（ステップＡ０３）。キュー監視部２２は、該当トランザクションデータＩＤ１４が管理テーブル２４に存在するか否かを判定する（ステップＡ０４）。キュー監視部２２は、該当トランザクションデータＩＤが管理テーブル２４に存在しないと判定した場合、当該トランザクションデータを処理すべきデータとみなす。すなわち、ステップＡ０５、ステップＡ１０、ステップＡ１１、ステップＡ１２が順次実行される。ステップＡ０２において、キュー監視部２２が、再送回数が１以上であることを確認し、ステップＡ０４において該当トランザクションデータＩＤが管理テーブル２４に存在しないと判定された以降の処理の流れをケース２とする。

ケース２における処理を実行することにより、ケース１においてステップＡ０５実行前、すなわち、特定のトランザクションデータを初めて処理するとき（再送回数＝０）のステップＡ０５実行前の時点（Ｐ０１）において、トランザクション処理部２１に障害が発生した場合でも正常に処理が行われる。つまり、ステップＡ０５の前に、トランザクション処理部２１に障害が発生しトランザクション処理が実行されないと、管理テーブル２１に当該トランザクションデータＩＤのレコードが新規登録されない。ケース２における処理を実行することにより、トランザクションデータの再送回数が１以上である場合であっても、当該トランザクションデータを用いたトランザクション処理は実行されていないことを検出し、トランザクション処理を正常に実行することが出来る。

ステップＡ０４において、キュー監視部２２は、該当トランザクションデータＩＤ１４のレコードがあった場合はその情報を取得する。管理テーブル２４には図３に示したように処理状況を示すステータス（状態）が記録されており、キュー監視部２２は、このステータスを確認する（ステップＡ０６）。取得したレコードの状態に関する項目が「ステータス＝完了」であった場合には、キュー監視部２２は、トランザクションデータを破棄する（ステップＡ０９＿１）。次に、キュー監視部２２は、確認応答をキュー入出力管理部１６へ出力する（ステップＡ１２）。ステップＡ０６において該当トランザクションデータＩＤが管理テーブル２４において、「ステータス＝完了」と設定されている場合以降の処理の流れをケース３とする。

ケース３における処理を実行することにより、トランザクションの実行が正常に完了（ステップＡ１０）し、管理テーブル２４中の該当トランザクションデータＩＤのステータスを完了で更新した後の時点（Ｐ０３）でトランザクション処理部２１に障害が発生した場合においても正常に処理が実行される。つまり、トランザクション処理部２１の障害発生によって、キュー監視部２２が、ステップＡ１２における確認応答をキュー入出力管理部１６へ出力することができなかったことを検出し、重複してトランザクション処理を実行することなく、キュー入出力管理部１６へ確認応答を出力することが出来る。

さらに、ケース３における処理を実行することにより、ステップＡ１２まで完了したがメッセージキュー管理部１１内のキュー入出力管理部１６の障害によって、メッセージキュー１２から該当トランザクションデータが削除できなかった場合にも対処することができる。さらに、ケース３における処理を実行することにより、ステップＡ１２まで完了したがネットワーク障害などにより確認応答がキュー入出力管理部１６に到達しなかった場合にも対処することが出来る。ここで言う対処とは、一連の処理が再度実行されステップＡ１０つまりトランザクションの実行（リソースの更新処理）が重複して実行されてしまうことを回避できることを意味する。

しかしながら、ここまでに述べたフローにおいても、トランザクション処理が実行されたのか実行されていないのか確定できない区間、いわゆるインダウト状態が発生しうる。具体的には、図中のＰ０２−１とＰ０２−２とにおいてトランザクション処理部２１に障害が発生するとインダウト状態になる（Ｐ０２−１はステップＡ１０の処理実行中の障害を含み、Ｐ０２−２はステップＡ１１の処理実行中の障害を含む）。

Ｐ０２−１において、トランザクション処理部２１に障害が発生した場合、トランザクション処理は実行されていない。そのため、キュー監視部２２が再度トランザクションデータ１８を取得した際に、サーバアプリケーション２３は、トランザクション処理を実行するべきである。一方、Ｐ０２−２において、トランザクション処理部２１に障害が発生した場合では、トランザクション処理は実行済みである。そのため、キュー監視部２２が再度トランザクションデータ１８を取得した際に、サーバアプリケーション２３は、トランザクションを実行してはいけない。しかしながら、これまでに述べた再配信回数１５や管理テーブル２４で確認するだけでは、Ｐ０２−１とＰ０２−２の区別ができない。

つまり、ステップＡ０６において、トランザクションＩＤのステータスが実行中である場合、キュー監視部２２は、当該トランザクションＩＤ１４に関するトランザクション処理がステップＡ１０において実行される前か、もしくはステップＡ１０において実行された後かを判定することが出来ない。

ここで、ステップＡ０６において、トランザクションＩＤ１４のステータスが完了ではない、と判定された場合の処理の流れについて説明する。以下に説明する処理の流れにおいては、Ｐ０２−１とＰ０２−２との区別をトランザクション装置２に登録可能なアプリケーション開発者のロジックに委譲することによってインダウト状態の解決を試行する。

前述のように、ステップＡ０６において、管理テーブル２４中の該当トランザクションデータＩＤのレコードが「ステータス＝実行中」の場合は、当該トランザクションを実行すべきか破棄すべきかの判断ができないインダウト状態となる。このようなケースにおいて、トランザクション処理装置２では、キュー監視部２２は、トランザクション判断プログラム２７を実行する（ステップＡ０７）。トランザクション判断プログラム２７は、インダウト状態を解決する任意のロジックを登録できるトランザクション判断プログラム登録部２６に登録されたプログラムであり、「新規」、「重複」、のいずれかを出力する（ステップＡ０８）。「重複」が出力された場合には、キュー監視部２２は、トランザクションデータ１８を破棄し（ステップＡ０９＿２）、管理テーブル２４内の該当トランザクションデータＩＤ１４のレコードを「ステータス＝完了」に更新し（ステップＡ１１）、確認応答をキュー入出力管理部１６へ出力する。ステップＡ０８から「新規」が出力された場合には、キュー監視部２２は、当該トランザクションデータ１８を処理すべきデータとみなした処理を行う。すなわち、ステップＡ１０、ステップＡ１１、ステップＡ１２を順次実行する。ステップＡ０７以降の処理の流れをケース４とする。

例えば、トランザクション判断プログラム２７は、未処理は絶対に許容できないが２重処理は問題にならないという場面では、必ず「新規」を出力してもよい。また、トランザクション判断プログラム２７は、未処理は問題にならないが２重処理を回避する必要のある場面では、必ず「重複」を出力してもよい。このように、トランザクション判断プログラム２７は、キュー監視部２２において取得したトランザクションデータ１８の内容に応じて、「新規」もしくは「重複」を出力してもよい。

図５には、図４において説明したケース１〜４において実行処理を判定する際の条件及び処理の実行内容が示されている。実行処理を判定する際の条件には、再送回数、トランザクションデータＩＤの存在有無及びトランザクションデータＩＤの状態について規定されている。また、実行内容は、アクションとして規定されている。

次に、図６を用いてトランザクション判断プログラム２７の具体例について説明する。ただし、トランザクション判断プログラム２７で実現できる判断ロジックは図６に示す例に限られない。

図６では、業務要件を判断に利用するトランザクション判断プログラム２７の例を示している。前提とする業務として、「トランザクションデータは、ＧＰＳ等で計測された位置情報を意味するデータである。トランザクションデータ内には時刻と座標が含まれている。サーバアプリケーション側では、最新時刻の位置情報を地図画面上の座標位置にプロットする。」というものを想定する。この場合、サーバアプリケーションが知りたいのは、常に最新の位置情報であり、既に取得した最新時刻のデータよりも古いデータを受信した場合には破棄する。つまりそのデータで地図画面を更新することはしない。

図６の処理フローを説明する。トランザクション判断プログラム２７は、キュー監視部２２から「新規」もしくは「重複」の判定が必要なトランザクションＩＤ１４を受け取る（ステップＥ０１）。次に、トランザクション判断プログラム２７は、受け取ったトランザクションＩＤ１４の情報を管理テーブル２４から検索し、トランザクションデータ１８の受信時刻情報(TX_TIME)を取得する（ステップＥ０２）。

次に、トランザクション判断プログラム２７は、管理テーブル２４において状態が「完了」となっている全トランザクションデータの時刻情報を取得し、取得した時刻情報の中から最新の時刻情報（LATEST_TIME）を抽出する（ステップＥ０３）。トランザクション判断プログラム２７は、TX_TIMEとLATEST_TIMEとにおいてどちらが新しい時間かを判定する（ステップＥ０４）。

TX_TIMEの方が古ければ、該当トランザクションデータよりも新しいトランザクションデータが既にサーバアプリケーションへ出力されているので、該当トランザクションデータをサーバアプリケーションへ出力する必要がない。実際にはTX_TIMEを取得したトランザクションデータがサーバアプリケーションに送信されていない（すなわち、図４のＰ０２−１で障害が発生した）かもしれない。しかし、サーバアプリケーションが知りたいのは常に最新の位置情報だけであるという業務要件から、TX_TIMEを取得したトランザクションデータをサーバアプリケーションへ送信する必要がないと決定できるロジックである。よって、トランザクション判断プログラム２７は、キュー監視部２２へ「重複」を出力する（ステップＤ０６）。

一方、TX_TIMEがLATEST_TIMEより新しければ、トランザクション判断プログラム２７は、キュー監視部２２へ新規を出力する（Ｅ０５）。結果として、TX_TIMEのトランザクションデータがサーバアプリケーションに送信される。実際にはTX_TIMEを取得したトランザクションデータがサーバアプリケーションに既に送信されている（すなわち、図４のＰ０２−２で障害が発生した）かもしれない。しかし、サーバアプリケーションがTX_TIMEのトランザクションデータで地図上の位置情報を更新しても、実際にはプロット位置が変わらないので弊害はない。

続いて、図７を用いてメッセージキュー管理部１１の動作を説明する。具体的には、トランザクションデータ受信時のキュー入出力管理部１６の動作について説明する。

はじめに、キュー入出力管理部１６は、クライアントアプリケーション１からトランザクションデータ１８を受信する（ステップＢ０１）。キュー入出力管理部１６は、トランザクションデータＩＤ発行部１９にトランザクションデータＩＤ１４の払い出しを要求し、トランザクションデータＩＤを取得し、トランザクションデータ１８に取得したトランザクションＩＤを設定する（ステップＢ０２）。次に、キュー入出力管理部１６は、「再送回数＝０」の再送回数情報をトランザクションデータ１８に設定し、トランザクションデータ１８をメッセージキュー１２に登録する（Ｂ０３）。

続いて、図８を用いてメッセージキュー管理部１１の動作を説明する。具体的には、トランザクションデータ送信時のキュー入出力管理部１６の動作について説明する。

はじめに、キュー入出力管理部１６は、キュー監視部２２からトランザクションデータ１８の送信要求を受け付ける（ステップＣ０１）。次に、キュー入出力管理部１６は、トランザクションデータ１８の有無を確認する（ステップＣ０２）。トランザクションデータ１８がない場合は、キュー入出力管理部１６は、トランザクションデータが存在しないことを示す情報をキュー監視部２２へ出力する（ステップＣ０３）。一方、トランザクションデータ１８が存在する場合は、キュー入出力管理部１６は、メッセージキュー１２からトランザクションデータ１８を取り出し、キュー監視部２２へ送信する（ステップＣ０４）。

キュー入出力管理部１６がキュー監視部２２へ送信したトランザクションデータ１８には、トランザクションデータＩＤ１４と再送回数情報１５とが設定されている。キュー入出力管理部１６は、キュー監視部２２から出力される受信結果の応答を確認し（ステップＣ０５）、正常に受信した旨の応答を得た場合には、当該トランザクションデータ１８の再送回数に１を加算し、処理を終了する（ステップＣ０６）。キュー入出力管理部１６は、キュー監視部２２から受信に失敗した旨の応答を得た場合には、ステップＣ０４の処理を再度実行する。

続いて、図９を用いてメッセージキュー管理部１１の動作を説明する。具体的には、トランザクションデータ１８削除時のキュー入出力管理部１６の動作について説明する。キュー入出力管理部１６は、キュー監視部２２から確認応答を受信すると（ステップＤ０１）、メッセージキュー１２から当該トランザクションデータＩＤ１４のトランザクションデータ１８を削除する（ステップＤ０２）。

以上説明したように、本発明の実施の形態２にかかるトランザクション処理装置を用いることにより、次のような効果を得られる。

第１の効果は、非同期メッセージキューを用いたトランザクション処理プログラムの更新先リソースが１相コミット・リソースである場合にも、トランザクションデータの消失や２重処理を発生させることなくトランザクションを実行できる点にある。その理由は、再送回数とトランザクションデータＩＤ、トランザクション判断プログラムを利用することで処理すべきトランザクションデータなのか重複なのかを判断できるためである。

第２の効果は、更新先リソースがデータベースである必要がなく、ファイルシステム上の通常のファイルなどでもよい点にある。言い換えると、トランザクションデータＩＤを管理する管理テーブルと更新先リソースとの更新を同時に確定できなくてもよい点にある。その理由は、トランザクション判断プログラムを利用して、更新済みか未更新かを決定できる機構を備えているからである。

第３の効果は、業務アプリケーション内に、未処理や２重処理を防ぐための機構を実装する必要がない点にある。その理由は、トランザクションＩＤの採番・付与・検証やトランザクション判断プログラムにおける処理を業務アプリケーション（クライアントアプリケーションとサーバアプリケーション）から分離した構成としているからである。

第４の効果は、既に存在している非同期メッセージキューを用いた業務アプリケーションに本発明を適用することが容易であるという点がある。その理由は、本発明のトランザクション処理装置内のサーバアプリケーション以外の部品を用意しサーバアプリケーションをキュー監視部２２から呼び出されるように配置し、かつ、クライアントアプリケーションのトランザクションデータ投入先を本発明のキュー入出力管理部１６に変更すれば、容易に本発明の構成を実現できるからである。

第５の効果は、更新対象リソースが複数あってもよい点にある。その理由は、トランザクション処理装置は、管理テーブル中においてトランザクションデータＩＤ及びリソース番号ごとのステータスを管理し、全てのリソースの更新が完了できてから非同期メッセージキュー内のメッセージを削除する。これによって、更新漏れリソースが生じることを防ぎ、かつ、トランザクションデータの再受信時に管理テーブルとトランザクション判断プログラムを利用することによって重複を検出することができるからである。

（実施の形態３）
続いて、図１０を用いて本発明の実施の形態３にかかるトランザクション処理装置２の構成例について説明する。図１０においては、トランザクション処理装置２は、図２のキュー監視部２２の代わりにメッセージ受信部３２を有している。図２においては、キュー監視部２２が、キュー入出力管理部１６へ能動的に取得要求を出す方法、つまり、ポーリング（一定間間隔で取得要求を出す）によってトランザクションデータを取得する方法を示した。一方、図１０に示すようにキュー入出力管理部１６が主体となってトランザクションデータを送信してもよい。この場合には、メッセージ受信部３２は、ポーリングによってトランザクションデータを受信するのではなく、キュー入出力管理部１６から主体的に送信されたトランザクションデータを受信する。キュー入出力管理部１６は、メッセージキュー１２にトランザクションデータが格納されるたびにメッセージ受信部３２へトランザクションデータを送信してもよく、定期的にメッセージキュー１２に格納されているトランザクションデータをメッセージ受信部３２へ送信してもよい。

以上説明したように、図１０におけるトランザクション処理装置を用いることにより、トランザクション処理部２１からメッセージキュー管理部１１へ取得要求メッセージを送信する必要がなくなるため、トランザクション処理部２１における処理を簡素化することが出来る。

（実施の形態４）
続いて、図１１を用いて本発明の実施の形態４にかかるトランザクション処理装置２の構成例について説明する。メッセージキュー管理部１１は、図２と同様であるため詳細な構成の説明を省略する。図１１のトランザクション処理装置２は、複数の更新対象のリソースがある場合を示している。図１１や下記の説明中では分かりやすくするためにリソースを２つにしているが、３つ以上あっても同様に実現できる。

ただし、図１１においては、各リソースが必ず１回更新されることを保証できるが、全てのリソースの更新を同時に確定できる訳ではない。つまり、リソース１は更新されたがリソース２は更新されていない、という状態が発生しえる。

図１１のトランザクション処理装置２は、メッセージ受信部３２から呼び出されるサーバアプリケーションが１つではなく２つ存在する（サーバアプリケーション２３＿１及びサーバアプリケーション２３＿２）。また、トランザクション判断プログラム登録部２６に登録されるプログラムがトランザクション判断プログラム２７＿１とトランザクション判断プログラム２７＿２との２つ存在する。その他の構成は図１や図９に示した構成と同等である。

続いて、図１２を用いて本発明の実施の形態４にかかる管理テーブル２４の構成例について説明する。図３に示した管理テーブル２４と構成が異なり、図１２の管理テーブル２４には、「リソース番号」列が追加されている。この管理テーブル２４では、主キーは、「トランザクションデータＩＤ」と「リソース番号」列の組になる。ステータス（状態）の値はそれぞれ以下を意味する。

・未実行：リソースは、該当のトランザクションデータを用いて更新されていない。
・実行中：リソースは、該当のトランザクションデータを用いて更新された可能性がある。
・完了：リソースは、該当のトランザクションデータを用いて更新された。

つまり、各行は、「各トランザクションデータＩＤを用いて各リソース更新処理を実行した状態が「未実行」か「実行中」か「完了」か」を意味する。「未実行」の場合は、メッセージ受信部３２は、サーバアプリケーションを実行し、「実行中」の場合はトランザクション判断プログラムを実行しその結果次第でサーバアプリケーションを実行するか否かを決定する。「完了」の場合は、メッセージ受信部３２は、トランザクションデータを廃棄する。

なお、リソース番号は、更新順ごとに登録するものとする。例えば、リソース番号１と２がある場合、リソース番号１の更新処理（２３−１のサーバアプリケーション１の実行）の後、リソース番号２の更新処理（２３−２のサーバアプリケーション２の実行）が行われる。

また、管理テーブル２４の項目（カラム）は、本実施の形態４における動作の説明に必要な最低限のカラムだけを示している。実際には、管理テーブル２４には、トランザクション判断プログラムの判断に利用できるように適宜項目が追加されてもよい。例えば、追加される項目として、トランザクションデータそのもの、再送回数、キュー入出力管理部１６から受信した時刻などが考えられるがこの限りではない。

次に、図１３を用いて、本実施例で使用されているトランザクション処理装置の動作を説明する。はじめに、図１３のケース１となるフローについて解説する。

メッセージ受信部３２は、キュー入出力管理部１６からトランザクションデータ１８を受信する（ステップＹ０１）。次に、メッセージ受信部３２は、トランザクションデータ１８に付与されている再送回数情報を確認する（ステップＹ０２）。再送回数が０の場合には、メッセージ受信部３２は、トランザクションデータＩＤ管理部２５に該当トランザクションデータＩＤ１４の情報をリソースごとに新規登録する。この時、メッセージ受信部３２は、リソース番号１を「ステータス＝実行中」、リソース番号ｎ（＞１）のリソースを「ステータス＝未実行」とする（ステップＹ１４）。前述の通り、リソース番号は更新順ごととしているため、リソース番号１は最初に更新するリソースである。

次に、メッセージ受信部３２は、処理対象リソース番号を表す変数ｎを「ｎ＝１」に設定する（ステップＹ１５）。処理対象リソース番号を表す変数ｎを１とすることによって、ステップＹ０９においてｎ＝１のリソースが処理対象となる。そのため、メッセージ受信部２２は、サーバアプリケーション２３＿１を呼び出し、サーバアプリケーション２３＿１は、リソース３＿１を更新する。

メッセージ受信部３２は、処理対象リソース番号を表す変数ｎが最後のリソースか判定を行う（ステップＹ１０）。ｎが最後のリソースである場合には、メッセージ受信部３２は、トランザクションデータＩＤ管理部２５に該当トランザクションデータＩＤ１４及びリソース番号ｎの情報を「ステータス＝完了」に更新する（ステップＹ１６）。さらに、メッセージ受信部３２は、確認応答をキュー入出力管理部２２へ出力する（ステップＹ１３）。

ステップＹ１０において、処理対象リソース番号を表す変数ｎが最後のリソースでないと判定された場合、メッセージ受信部３２は、次のリソース番号の処理に移る。まず、メッセージ受信部３２は、トランザクションデータＩＤ管理部２５にトランザクションデータＩＤ及びリソース番号ｎの行を「ステータス＝完了」に更新し、かつ、トランザクションデータＩＤ及びリソース番号ｎ＋１の情報を「ステータス＝実行中」に更新する（ステップＹ１１）。この２行の更新は、同一データベース内で行われるため同時に確定する。次に、処理対象リソース番号ｎに１を加算（ステップＹ１２）し、ステップＹ０９に戻る。この後、最後のリソースまで順次処理を繰り返す。

次に、図１３のケース２となるフローについて説明する。ステップＹ０２において、再送回数が０より大きいと判定された場合、管理テーブル２４から該当トランザクションデータＩＤの情報を検索する（ステップＹ０３）。キュー監視部２２は、該当トランザクションデータＩＤが存在するかを確認し（ステップＹ０４）、存在しない場合はケース１と同様に、当該トランザクションデータを処理すべきデータとみなした処理を行う。すなわち、ステップＹ１４に遷移し、以降の処理を行う。

ケース２の処理を実行することにより、ケース１においてステップＹ１４実行前、すなわち、特定のトランザクションデータを初めて処理するとき（再送回数＝０）のステップＹ１４実行前の時点（Ｐ０１）に障害が発生した場合においても、正しく処理を行うことが出来る。つまり、Ｐ０１において、トランザクション処理部２１に障害が発生し、管理テーブル２４に当該トランザクションデータＩＤのレコードを新規登録できなかった場合でも、メッセージ受信部３２が該当のトランザクションデータを再取得した時に、トランザクションデータの消失や、サーバアプリケーション２３においてトランザクションデータの２重処理が発生することなく正しく処理できることを可能としている。

ステップＹ０４において、メッセージ受信部３２は、該当トランザクションデータＩＤが存在すると判定した場合、管理テーブル２４中の該当トランザクションデータＩＤの各リソース番号のステータス（状態）を確認する。メッセージ受信部３２は、全てのリソース番号の行において「ステータス＝完了」となっているかを確認する（ステップＹ０５）。メッセージ受信部３２は、全てのリソース番号の行において「ステータス＝完了」となっていることを確認した場合（YESの場合）には、全リソースが該当トランザクションデータＩＤのトランザクションデータで更新済みであるので、トランザクションデータを破棄（ステップＹ１７）し、確認応答をメッセージキューへ出力する（ステップＹ１３）。ここで、ステップＹ０５の判定がYESの場合をケース３とする。

ケース３により、最後のリソースに対してステップＹ０９、Ｙ１０、Ｙ１６の処理完了後、すなわち、トランザクションの実行が正常に完了（ステップＹ０９）し、管理テーブル２４中の該当トランザクションデータＩＤの最後のリソース番号の行を「ステータス＝完了」で更新した後の時点（Ｐ０３）に障害が発生した場合においても正しく処理をすることが出来る。すなわち、Ｐ０３においてトランザクション処理部２１に障害が発生し、ステップＹ１３の確認応答をメッセージキューへ出力できなかった場合に対処している。

また、ステップＹ１３まで完了したがメッセージキュー管理部１１内のキュー入出力管理部１６の障害によってメッセージキュー１２から該当トランザクションデータが削除できなかった場合や、ステップＹ１３まで完了したがネットワーク障害などにより確認応答がキュー入出力管理部１６に到達しなかった場合にも対処している。ここで言う対処とは、一連の処理が再度実行されステップＹ０９つまりトランザクションの実行（リソースの更新処理）が重複して実行されてしまうことを回避できることを意味する。

続いて、ケース４となるフローについて説明する。ステップＹ０５の判定において、「ステータス＝実行中」であるリソースが存在する場合、そのリソース番号を取得し、処理対象リソース番号を表す変数ｎをその番号に設定する（ステップＹ０６）。前述の通り、このリソースｎはサーバアプリケーションｎによる更新処理（ステップＹ０９）が実行されたか否か判定できないので、メッセージ受信部３２は、リソースｎ用のトランザクション判断プログラムｎを実行する（ステップＹ０７）。トランザクション判断プログラムｎの結果が「重複」を示すかを判定し（ステップＹ０８）、重複を示す場合には２重処理を防ぐためにサーバアプリケーションｎの実行（ステップＹ０９）は行わずに次のリソースの処理にうつる。すなわち、ステップＹ１０にうつり、以降の処理を行う。「重複」ではなく「新規」を示す場合、サーバアプリケーションｎによるトランザクション実行（リソースｎの更新）後（ステップＹ０９）、次のリソースの処理にうつる。

「ステータス＝実行中」となっているリソースに関しては、リソースが更新済みなのか更新されていないのか判断ができないので、トランザクション判断プログラムで判断する。「ステータス＝実行中」となりうるポイントについて以下に説明する。

・Ｐ０２−１：Ｙ１４の完了後、かつ、Ｙ０９の完了前の時点。
ここでトランザクション処理装置２に障害が発生した場合、管理テーブル中のリソースｎ（ｎ＝１）の更新は完了していない。そのため、管理テーブル中の該当リソース番号（ｎ＝１）のステータスが「実行中」のままとなる。メッセージ受信部３２が当該トランザクションデータＩＤのトランザクションデータを再度受信した時、ケース４の遷移となり、ステップＹ０７においてリソースｎに対するトランザクション判断プログラムが実行される。

・Ｐ０２−２：Ｙ０９の完了後、かつ、ステップＹ１１の完了前の時点、および、Ｙ０９の完了後、かつ、ステップＹ１６の完了前の時点。
ここでトランザクション処理装置２に障害が発生した場合、リソースｎの更新は完了しているが管理テーブル２４中で該当リソース番号のステータスが「実行中」のままとなる。そのため、メッセージ受信部３２が当該トランザクションデータＩＤのトランザクションデータを再度受信した時、ケース４の遷移となり、ステップＹ０７においてリソースｎに対するトランザクション判断プログラムが実行される。

・Ｐｏｉｎｔ０２−３：リソース番号ｎに対するＹ１１の完了後、かつ、次のリソース番号（ｎ＝ｎ＋１）に対するＹ０９の実行完了前の時点。
ここでトランザクション処理装置２に障害が発生した場合、リソースｎの更新は完了し、リソースｎ＋１の更新は完了していない。管理テーブル中のリソース番号ｎのステータスは「完了」、リソース番号ｎ＋１のステータスは「実行中」となっている。そのため、メッセージ受信部３２が当該トランザクションデータＩＤのトランザクションデータを再度受信した時、ケース４の遷移となり、ステップＹ０６では「ステータス＝実行中」となっているリソース番号として（ｎ＋１）が取得される。よって、ステップＹ０７においてリソースｎ＋１に対するトランザクション判断プログラムｎ＋１が実行される。

以上説明したように、本発明の実施の形態３にかかるトランザクション処理装置２を用いることにより、トランザクション処理装置２が複数のリソースを更新する場合においても、リソースの２重更新もしくはリソースの更新漏れ等を防ぐことが出来る。

上述の実施の形態では、本発明をハードウェアの構成として説明したが、本発明は、これに限定されるものではない。本発明は、図４及び図１３におけるトランザクション処理装置の処理を、ＣＰＵ（Central Processing Unit）にコンピュータプログラムを実行させることにより実現することも可能である。）

上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Read Only Memory）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（Random Access Memory））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。

（付記１）入力されたトランザクションデータを保持するメッセージキュー管理部と、前記トランザクションデータを用いてトランザクション処理を実行するトランザクション処理部と、を備え、前記メッセージキュー管理部は、前記トランザクションデータを前記トランザクション処理部へ出力した回数を示す再送回数を前記トランザクションデータと対応付けて管理し、前記トランザクション処理部は、前記メッセージキュー管理部から前記トランザクションデータとともに前記再送回数に関する情報を併せて取得し、前記再送回数に関する情報に再送が行われていないことを示す値が設定されている場合、前記トランザクション処理を実行する、トランザクション処理装置。

（付記２）前記トランザクション処理部は、前記トランザクションデータの前記トランザクション処理の状況を示すステータス情報を含む情報を管理する管理テーブルをさらに備え、前記トランザクション処理部は、前記トランザクションデータの再送回数に関する情報に、過去に前記トランザクションデータの再送を実行したことがあることを示す値が設定され、かつ、前記管理テーブルに前記トランザクションデータのステータス情報が管理されていない場合に前記トランザクション処理を実行する、付記１に記載のトランザクション処理装置。

（付記３）前記トランザクション処理部は、前記トランザクションデータの再送回数に関する情報に、過去に前記トランザクションデータの再送を実行したことがあることを示す値が設定され、かつ、前記管理テーブルに管理されている前記トランザクションデータのステータス情報がトランザクション処理の完了を示している場合、前記メッセージキュー管理部から取得した前記トランザクションデータを破棄する、付記２に記載のトランザクション処理装置。

（付記４）前記トランザクション処理部は、前記トランザクションデータの再送回数に関する情報に、過去に前記トランザクションデータの再送を実行したことがあることを示す値が設定され、かつ、前記管理テーブルに管理されている前記トランザクションデータのステータス情報がトランザクション処理の完了を示していない場合、前記トランザクション処理の内容に応じて前記トランザクション処理の実行もしくは不実行を判定するトランザクション判断プログラムに従い前記トランザクション処理を実行するか否かを判定する、付記２又は３に記載のトランザクション処理装置。

（付記５）前記トランザクション判断プログラムは、前記管理テーブルにおいて管理されている情報に基づいて、前記トランザクション処理を実行するか否かを判定する、付記４に記載のトランザクション処理装置。

（付記６）前記トランザクション判断プログラムは、前記メッセージキュー管理部から取得した前記トランザクションデータが生成された時刻情報が、前記管理テーブルに記録されたトランザクションデータが生成された時刻情報よりも新しい場合、前記トランザクション処理を実行する、付記４又は５に記載のトランザクション処理装置。

（付記７）前記トランザクション処理部は、前記メッセージキュー管理部へトランザクションデータの送信要求メッセージを送信した後に前記トランザクションデータを前記メッセージキュー管理部から取得する、付記１乃至６のいずれか１項に記載のトランザクション処理装置。

（付記８）前記メッセージキュー管理部は、前記トランザクションデータを保持すると、前記トランザクションデータを前記トランザクション処理部へ出力し、前記トランザクション処理部は、前記メッセージキュー管理部から出力された前記トランザクションデータを取得する、付記１乃至６のいずれか１項に記載のトランザクション処理装置。

（付記９）トランザクションデータを出力するクライアントアプリケーションと、前記出力されたトランザクションデータを保持するメッセージキュー管理部と、前記トランザクションデータを用いてトランザクション処理を実行するトランザクション処理部と、を有するトランザクション処理装置と、前記トランザクション処理が実行されることにより更新されるリソースを保持するデータ格納装置と、を備えるトランザクション処理システムであって、前記メッセージキュー管理部は、前記トランザクションデータを前記トランザクション処理部へ出力した回数を示す再送回数を前記トランザクションデータと対応付けて管理し、前記トランザクション処理部は、前記メッセージキュー管理部から前記トランザクションデータとともに前記再送回数に関する情報を併せて取得し、前記再送回数に関する情報に再送が行われていないことを示す値が設定されている場合、前記トランザクション処理を実行する、トランザクション処理システム。

（付記１０）入力されたトランザクションデータを保持し、前記トランザクションデータを用いてトランザクション処理を実行するトランザクション処理部へ、前記トランザクションデータを出力した回数を示す再送回数を前記トランザクションデータに設定し、
前記再送回数に関する情報に再送が行われていないことを示す値が設定されている場合、前記トランザクションデータを用いて前記トランザクション処理を実行する、トランザクション処理方法。

（付記１１）入力されたトランザクションデータを保持するステップと、前記トランザクションデータを用いてトランザクション処理を実行するトランザクション処理部へ、前記トランザクションデータを出力した回数を示す再送回数を前記トランザクションデータに設定するステップと、前記再送回数に関する情報に再送が行われていないことを示す値が設定されている場合、前記トランザクションデータを用いて前記トランザクション処理を実行するステップと、をコンピュータに実行させるプログラム。

１ クライアントアプリケーション
２ トランザクション処理装置
３ リソース
１１ メッセージキュー管理部
１２ メッセージキュー
１６ キュー入出力管理部
１７ 再送回数管理部
１９ トランザクションデータＩＤ発行部
２１ トランザクション処理部
２２ キュー監視部
２３ サーバアプリケーション
２４ 管理テーブル
２５ トランザクションデータＩＤ管理部
２６ トランザクション判断プログラム登録部
３２ メッセージ受信部

Claims (10)

1. 入力されたトランザクションデータを保持するメッセージキュー管理部と、
   前記トランザクションデータを用いてトランザクション処理を実行するトランザクション処理部と、を備え、
   前記メッセージキュー管理部は、
   前記トランザクションデータを前記トランザクション処理部へ出力した回数を示す再送回数を前記トランザクションデータと対応付けて管理し、
   前記トランザクション処理部は、
   前記メッセージキュー管理部から前記トランザクションデータとともに前記再送回数に関する情報を併せて取得し、前記再送回数に関する情報に再送が行われていないことを示す値が設定されている場合、前記トランザクション処理を実行する、トランザクション処理装置。
2. 前記トランザクション処理部は、
   前記トランザクションデータの前記トランザクション処理の状況を示すステータス情報を含む情報を管理する管理テーブルをさらに備え、
   前記トランザクション処理部は、
   前記トランザクションデータの再送回数に関する情報に、過去に前記トランザクションデータの再送を実行したことがあることを示す値が設定され、かつ、前記管理テーブルに前記トランザクションデータのステータス情報が管理されていない場合に前記トランザクション処理を実行する、請求項１に記載のトランザクション処理装置。
3. 前記トランザクション処理部は、
   前記トランザクションデータの再送回数に関する情報に、過去に前記トランザクションデータの再送を実行したことがあることを示す値が設定され、かつ、前記管理テーブルに管理されている前記トランザクションデータのステータス情報がトランザクション処理の完了を示している場合、前記メッセージキュー管理部から取得した前記トランザクションデータを破棄する、請求項２に記載のトランザクション処理装置。
4. 前記トランザクション処理部は、
   前記トランザクションデータの再送回数に関する情報に、過去に前記トランザクションデータの再送を実行したことがあることを示す値が設定され、かつ、前記管理テーブルに管理されている前記トランザクションデータのステータス情報がトランザクション処理の完了を示していない場合、前記トランザクション処理の内容に応じて前記トランザクション処理の実行もしくは不実行を判定するトランザクション判断プログラムに従い前記トランザクション処理を実行するか否かを判定する、請求項２又は３に記載のトランザクション処理装置。
5. 前記トランザクション判断プログラムは、
   前記管理テーブルにおいて管理されている情報に基づいて、前記トランザクション処理を実行するか否かを判定する、請求項４に記載のトランザクション処理装置。
6. 前記トランザクション判断プログラムは、
   前記メッセージキュー管理部から取得した前記トランザクションデータが生成された時刻情報が、前記管理テーブルに記録されたトランザクションデータが生成された時刻情報よりも新しい場合、前記トランザクション処理を実行する、請求項４又は５に記載のトランザクション処理装置。
7. 前記トランザクション処理部は、
   前記メッセージキュー管理部へトランザクションデータの送信要求メッセージを送信した後に前記トランザクションデータを前記メッセージキュー管理部から取得する、請求項１乃至６のいずれか１項に記載のトランザクション処理装置。
8. トランザクションデータを出力するクライアントアプリケーションと、
   前記出力されたトランザクションデータを保持するメッセージキュー管理部と、前記トランザクションデータを用いてトランザクション処理を実行するトランザクション処理部と、を有するトランザクション処理装置と、
   前記トランザクション処理が実行されることにより更新されるリソースを保持するデータ格納装置と、を備えるトランザクション処理システムであって、
   前記メッセージキュー管理部は、
   前記トランザクションデータを前記トランザクション処理部へ出力した回数を示す再送回数を前記トランザクションデータと対応付けて管理し、
   前記トランザクション処理部は、
   前記メッセージキュー管理部から前記トランザクションデータとともに前記再送回数に関する情報を併せて取得し、前記再送回数に関する情報に再送が行われていないことを示す値が設定されている場合、前記トランザクション処理を実行する、トランザクション処理システム。
9. 入力されたトランザクションデータを保持し、
   前記トランザクションデータを用いてトランザクション処理を実行するトランザクション処理部へ、前記トランザクションデータを出力した回数を示す再送回数を前記トランザクションデータに設定し、
   前記再送回数に関する情報に再送が行われていないことを示す値が設定されている場合、前記トランザクションデータを用いて前記トランザクション処理を実行する、トランザクション処理方法。
10. 入力されたトランザクションデータを保持するステップと、
    前記トランザクションデータを用いてトランザクション処理を実行するトランザクション処理部へ、前記トランザクションデータを出力した回数を示す再送回数を前記トランザクションデータに設定するステップと、
    前記再送回数に関する情報に再送が行われていないことを示す値が設定されている場合、前記トランザクションデータを用いて前記トランザクション処理を実行するステップと、をコンピュータに実行させるプログラム。

Images