(実施の形態1)
以下、図面を参照して本発明の実施の形態について説明する。図1を用いて本発明の実施の形態1にかかるトランザクション処理装置2の構成例について説明する。トランザクション処理装置2は、メッセージキュー管理部11及びトランザクション処理部21を有している。
メッセージキュー管理部11は、入力されたトランザクションデータを保持する。さらに、メッセージキュー管理部11は、入力されたトランザクションデータと、このトランザクションデータをトランザクション処理部21へ出力した回数を示す再送回数とを対応付けて管理する。メッセージキュー管理部11は、トランザクション処理部21からトランザクションデータの出力指示を受けると、トランザクションデータをトランザクション処理部21へ出力する。また、トランザクション処理部21は、受け取ったトランザクションデータを用いて正常にトランザクション処理を完了することが出来なかった場合、再度同じトランザクションデータの出力を指示する場合がある。このような場合に、メッセージキュー管理部11は、トランザクションデータを再送する。
トランザクション処理部21は、メッセージキュー管理部11から出力されたトランザクションデータを用いてトランザクション処理を実行する。トランザクション処理は、例えば、トランザクションデータを用いてリソースを更新する処理等であってもよい。トランザクション処理部21は、メッセージキュー管理部11からトランザクションデータを取得するとともに、トランザクションデータの再送回数に関する情報も併せて取得する。ここで、トランザクション処理部21は、トランザクションデータの再送回数に関する情報に、過去に再送が行われていないことを示す値が設定されている場合、例えば、再送回数が0回であるとの値が設定されている場合、トランザクション処理を実行する。
以上説明したように、図1のトランザクション処理装置2を用いることにより、トランザクションデータを出力するクライアントアプリケーション等において、重複したトランザクション処理を回避するためにのみ用いられるトランザクションデータのID等を付与する必要がなくなる。つまり、トランザクション処理装置2は、ID等が付与されていないトランザクションデータを受け取り、トランザクション処理装置2内におけるトランザクションデータの再送回数を管理する。これより、トランザクションデータを出力するクライアントアプリケーション等は、トランザクション処理装置2内における重複したトランザクション処理の回避に用いられる情報を付与する必要がなく、トランザクション処理の回避のために新たな機能追加等を行う必要がない。
(実施の形態2)
続いて、図2を用いて本発明の実施の形態2にかかるトランザクション処理装置2の構成例について主に説明する。図2において、図1と同様の機能を有する構成要素には、図1と同様の符号を付して説明する。トランザクション処理装置2は、クライアントアプリケーション1及びリソース3と通信を行う。
クライアントアプリケーション1は、トランザクション処理装置2にトランザクションデータを投入するアプリケーションである。
リソース3は、トランザクション処理装置2が更新の対象とするリソースである。リソース3は、例えば、ファイルシステム上のファイルが考えられるが、トランザクション処理装置2の制御外のアプリケーションに対してリソース更新を意味する要求を送信することも考えられる(HTTPのPOSTメソッドなど)。リソース3は、メモリ等のデータ格納装置に格納されるデータであってもよい。
トランザクション処理装置2は、メッセージキュー管理部11及びトランザクション処理部21を有している。さらにメッセージキュー管理部11は、メッセージキュー12、キュー入出力管理部16、再送回数管理部17及びトランザクションデータID発行部19を有している。
キュー入出力管理部16は、クライアントアプリケーション1から出力されたトランザクションデータ18を受け取る。トランザクションデータID発行部19は、受信したトランザクションデータ18に対して、一意のトランザクションデータID14を払い出す。メッセージキュー12は、キュー入出力管理部16において受け取ったトランザクションデータ18を格納する。再送回数管理部17は、トランザクション処理部21に対するトランザクションデータ18の送信回数(再送回数)を管理する。
トランザクションデータ18は、トランザクションデータID14及び再送回数情報が関連付けられてメッセージキュー12に格納される。
続いて、トランザクション処理部21の構成例について説明する。トランザクション処理部21は、キュー監視部22、トランザクションデータID管理部25、トランザクション判断プログラム登録部26及びサーバアプリケーション23を有している。
キュー監視部22は、メッセージキュー12に格納されたトランザクションデータ18を取得するための送信要求もしくはメッセージキュー12に格納されたトランザクションデータ18を削除するための確認応答をキュー入出力管理部16へ送信する。
トランザクションデータID管理部25は、キュー監視部22において取得したトランザクションデータに関する情報を格納する。トランザクション判断プログラム登録部26は、トランザクションを実行するか否かを規定したトランザクション判断プログラム27を登録する。トランザクション判断プログラム27については、後に詳述する。サーバアプリケーション23は、トランザクションデータ18を用いてリソース3を更新する。
トランザクションデータID管理部25は、管理テーブル24を有する。ここで、図3を用いて管理テーブル24の構成例を示す。管理テーブル24には、各トランザクションデータIDの状態が「実行中」もしくは「完了」として登録されている。なお、管理テーブル24内の項目(カラム)は、後述するトランザクション判断プログラム27の判断に利用できるように適宜増やしてもしてもよい。例えば、トランザクションデータの項目には、各トランザクションデータが、データの種別としてテストデータであることが示されている。再送回数の項目には、各トランザクションデータをトランザクション処理部21へ再送した回数が示されている。受信時刻の項目には、トランザクション処理部21が、各トランザクションデータをメッセージキュー管理部11から取得した時刻が示されている。
ここで、トランザクション処理装置2の利用者(一般にアプリケーション開発者)は、サーバアプリケーション23とトランザクション判断プログラム27をトランザクション処理装置2に実装する。さらに、トランザクション処理装置2の利用者は、クライアントアプリケーションも開発する。
サーバアプリケーション23は、1相コミット・リソースを更新するプログラムである。サーバアプリケーション23は、ファイルシステム上のファイルを更新するプログラムである場合や、トランザクション処理装置2とネットワークを介して接続された外部のトランザクション処理装置内のトランザクション処理プログラムを呼び出すプログラムである場合であってもよい。いずれの場合も、リソース3は、2相コミットに対応していないため、リソース3の更新とメッセージキュー12の更新(トランザクションデータ18の削除)とは、同一のトランザクション内で実行されない。なお、クライアントアプリケーション1とサーバアプリケーション23とをあわせて業務アプリケーションと定義してもよい。
トランザクション判断プログラム27は、リソース3の更新処理が完了しているかをトランザクションデータID管理部25内の管理テーブル24から判断できない場合に、キュー監視部22において利用されるプログラムである。トランザクション判断プログラム27は、トランザクションデータIDを入力パラメータに持ち、当該トランザクションデータIDのトランザクションが実行完了したことを意味する「重複」か、実行失敗ことを意味する「新規」を出力する。どのようなルールに基づいて判断するかはアプリケーション開発者が決定してもよい。トランザクション判断プログラム27は、管理テーブル24内に格納された再送回数もしくは受信時刻等を利用してもよく、トランザクション処理装置のログ情報を利用してもよい。トランザクション判断プログラム27の具体例については、後述する。
続いて、図4を用いてトランザクション処理装置2における処理の流れについて説明する。
はじめに、トランザクション処理部21内のキュー監視部22は、キュー入出力管理部16経由でメッセージキュー12を監視する。キュー監視部22は、メッセージキュー12にトランザクションデータ18が格納されていることを検出した場合、トランザクションデータ18を取得する。その際、キュー監視部22は、トランザクションデータ18の他に、トランザクションデータ18に付随するトランザクションデータID14と再送回数に関する情報(再送回数情報)とも併せて取得する(ステップA01)。
次に、キュー監視部22は、再送回数情報を確認する(ステップA02)。キュー監視部22は、再送回数情報が「再送回数=0」の場合、メッセージキュー12から取得したトランザクションデータ18を処理すべきデータとみなす。この場合、キュー監視部22は、トランザクションデータID管理部25内の管理テーブル24にトランザクションデータ18のレコードを新規登録する。キュー監視部22は、トランザクションデータ18を登録する際に「ステータス(状態)=実行中」として登録する(ステップA05)。次に、サーバアプリケーション23は、トランザクション処理を実行する(ステップA10)。トランザクション処理の実行後、キュー監視部22は、管理テーブル24内の該当トランザクションデータID14のレコードを「ステータス=完了」へ更新する(ステップA11)。最後に、キュー監視部22は、確認応答をキュー入出力管理部16へ出力する(ステップA12)。後述するが、キュー入出力管理部16は、確認応答を受信すると該当するトランザクションデータ18をメッセージキュー12から削除する。ステップA02において、キュー監視部22が、再送回数=0であることを確認した以降の処理の流れをケース1とする。
ステップA02において、キュー監視部22は、再送回数が1以上の場合、トランザクションデータID管理部25中の管理テーブル24からステップA01で取得したトランザクションデータID14と一致するレコードを検索する(ステップA03)。キュー監視部22は、該当トランザクションデータID14が管理テーブル24に存在するか否かを判定する(ステップA04)。キュー監視部22は、該当トランザクションデータIDが管理テーブル24に存在しないと判定した場合、当該トランザクションデータを処理すべきデータとみなす。すなわち、ステップA05、ステップA10、ステップA11、ステップA12が順次実行される。ステップA02において、キュー監視部22が、再送回数が1以上であることを確認し、ステップA04において該当トランザクションデータIDが管理テーブル24に存在しないと判定された以降の処理の流れをケース2とする。
ケース2における処理を実行することにより、ケース1においてステップA05実行前、すなわち、特定のトランザクションデータを初めて処理するとき(再送回数=0)のステップA05実行前の時点(P01)において、トランザクション処理部21に障害が発生した場合でも正常に処理が行われる。つまり、ステップA05の前に、トランザクション処理部21に障害が発生しトランザクション処理が実行されないと、管理テーブル21に当該トランザクションデータIDのレコードが新規登録されない。ケース2における処理を実行することにより、トランザクションデータの再送回数が1以上である場合であっても、当該トランザクションデータを用いたトランザクション処理は実行されていないことを検出し、トランザクション処理を正常に実行することが出来る。
ステップA04において、キュー監視部22は、該当トランザクションデータID14のレコードがあった場合はその情報を取得する。管理テーブル24には図3に示したように処理状況を示すステータス(状態)が記録されており、キュー監視部22は、このステータスを確認する(ステップA06)。取得したレコードの状態に関する項目が「ステータス=完了」であった場合には、キュー監視部22は、トランザクションデータを破棄する(ステップA09_1)。次に、キュー監視部22は、確認応答をキュー入出力管理部16へ出力する(ステップA12)。ステップA06において該当トランザクションデータIDが管理テーブル24において、「ステータス=完了」と設定されている場合以降の処理の流れをケース3とする。
ケース3における処理を実行することにより、トランザクションの実行が正常に完了(ステップA10)し、管理テーブル24中の該当トランザクションデータIDのステータスを完了で更新した後の時点(P03)でトランザクション処理部21に障害が発生した場合においても正常に処理が実行される。つまり、トランザクション処理部21の障害発生によって、キュー監視部22が、ステップA12における確認応答をキュー入出力管理部16へ出力することができなかったことを検出し、重複してトランザクション処理を実行することなく、キュー入出力管理部16へ確認応答を出力することが出来る。
さらに、ケース3における処理を実行することにより、ステップA12まで完了したがメッセージキュー管理部11内のキュー入出力管理部16の障害によって、メッセージキュー12から該当トランザクションデータが削除できなかった場合にも対処することができる。さらに、ケース3における処理を実行することにより、ステップA12まで完了したがネットワーク障害などにより確認応答がキュー入出力管理部16に到達しなかった場合にも対処することが出来る。ここで言う対処とは、一連の処理が再度実行されステップA10つまりトランザクションの実行(リソースの更新処理)が重複して実行されてしまうことを回避できることを意味する。
しかしながら、ここまでに述べたフローにおいても、トランザクション処理が実行されたのか実行されていないのか確定できない区間、いわゆるインダウト状態が発生しうる。具体的には、図中のP02−1とP02−2とにおいてトランザクション処理部21に障害が発生するとインダウト状態になる(P02−1はステップA10の処理実行中の障害を含み、P02−2はステップA11の処理実行中の障害を含む)。
P02−1において、トランザクション処理部21に障害が発生した場合、トランザクション処理は実行されていない。そのため、キュー監視部22が再度トランザクションデータ18を取得した際に、サーバアプリケーション23は、トランザクション処理を実行するべきである。一方、P02−2において、トランザクション処理部21に障害が発生した場合では、トランザクション処理は実行済みである。そのため、キュー監視部22が再度トランザクションデータ18を取得した際に、サーバアプリケーション23は、トランザクションを実行してはいけない。しかしながら、これまでに述べた再配信回数15や管理テーブル24で確認するだけでは、P02−1とP02−2の区別ができない。
つまり、ステップA06において、トランザクションIDのステータスが実行中である場合、キュー監視部22は、当該トランザクションID14に関するトランザクション処理がステップA10において実行される前か、もしくはステップA10において実行された後かを判定することが出来ない。
ここで、ステップA06において、トランザクションID14のステータスが完了ではない、と判定された場合の処理の流れについて説明する。以下に説明する処理の流れにおいては、P02−1とP02−2との区別をトランザクション装置2に登録可能なアプリケーション開発者のロジックに委譲することによってインダウト状態の解決を試行する。
前述のように、ステップA06において、管理テーブル24中の該当トランザクションデータIDのレコードが「ステータス=実行中」の場合は、当該トランザクションを実行すべきか破棄すべきかの判断ができないインダウト状態となる。このようなケースにおいて、トランザクション処理装置2では、キュー監視部22は、トランザクション判断プログラム27を実行する(ステップA07)。トランザクション判断プログラム27は、インダウト状態を解決する任意のロジックを登録できるトランザクション判断プログラム登録部26に登録されたプログラムであり、「新規」、「重複」、のいずれかを出力する(ステップA08)。「重複」が出力された場合には、キュー監視部22は、トランザクションデータ18を破棄し(ステップA09_2)、管理テーブル24内の該当トランザクションデータID14のレコードを「ステータス=完了」に更新し(ステップA11)、確認応答をキュー入出力管理部16へ出力する。ステップA08から「新規」が出力された場合には、キュー監視部22は、当該トランザクションデータ18を処理すべきデータとみなした処理を行う。すなわち、ステップA10、ステップA11、ステップA12を順次実行する。ステップA07以降の処理の流れをケース4とする。
例えば、トランザクション判断プログラム27は、未処理は絶対に許容できないが2重処理は問題にならないという場面では、必ず「新規」を出力してもよい。また、トランザクション判断プログラム27は、未処理は問題にならないが2重処理を回避する必要のある場面では、必ず「重複」を出力してもよい。このように、トランザクション判断プログラム27は、キュー監視部22において取得したトランザクションデータ18の内容に応じて、「新規」もしくは「重複」を出力してもよい。
図5には、図4において説明したケース1〜4において実行処理を判定する際の条件及び処理の実行内容が示されている。実行処理を判定する際の条件には、再送回数、トランザクションデータIDの存在有無及びトランザクションデータIDの状態について規定されている。また、実行内容は、アクションとして規定されている。
次に、図6を用いてトランザクション判断プログラム27の具体例について説明する。ただし、トランザクション判断プログラム27で実現できる判断ロジックは図6に示す例に限られない。
図6では、業務要件を判断に利用するトランザクション判断プログラム27の例を示している。前提とする業務として、「トランザクションデータは、GPS等で計測された位置情報を意味するデータである。トランザクションデータ内には時刻と座標が含まれている。サーバアプリケーション側では、最新時刻の位置情報を地図画面上の座標位置にプロットする。」というものを想定する。この場合、サーバアプリケーションが知りたいのは、常に最新の位置情報であり、既に取得した最新時刻のデータよりも古いデータを受信した場合には破棄する。つまりそのデータで地図画面を更新することはしない。
図6の処理フローを説明する。トランザクション判断プログラム27は、キュー監視部22から「新規」もしくは「重複」の判定が必要なトランザクションID14を受け取る(ステップE01)。次に、トランザクション判断プログラム27は、受け取ったトランザクションID14の情報を管理テーブル24から検索し、トランザクションデータ18の受信時刻情報(TX_TIME)を取得する(ステップE02)。
次に、トランザクション判断プログラム27は、管理テーブル24において状態が「完了」となっている全トランザクションデータの時刻情報を取得し、取得した時刻情報の中から最新の時刻情報(LATEST_TIME)を抽出する(ステップE03)。トランザクション判断プログラム27は、TX_TIMEとLATEST_TIMEとにおいてどちらが新しい時間かを判定する(ステップE04)。
TX_TIMEの方が古ければ、該当トランザクションデータよりも新しいトランザクションデータが既にサーバアプリケーションへ出力されているので、該当トランザクションデータをサーバアプリケーションへ出力する必要がない。実際にはTX_TIMEを取得したトランザクションデータがサーバアプリケーションに送信されていない(すなわち、図4のP02−1で障害が発生した)かもしれない。しかし、サーバアプリケーションが知りたいのは常に最新の位置情報だけであるという業務要件から、TX_TIMEを取得したトランザクションデータをサーバアプリケーションへ送信する必要がないと決定できるロジックである。よって、トランザクション判断プログラム27は、キュー監視部22へ「重複」を出力する(ステップD06)。
一方、TX_TIMEがLATEST_TIMEより新しければ、トランザクション判断プログラム27は、キュー監視部22へ新規を出力する(E05)。結果として、TX_TIMEのトランザクションデータがサーバアプリケーションに送信される。実際にはTX_TIMEを取得したトランザクションデータがサーバアプリケーションに既に送信されている(すなわち、図4のP02−2で障害が発生した)かもしれない。しかし、サーバアプリケーションがTX_TIMEのトランザクションデータで地図上の位置情報を更新しても、実際にはプロット位置が変わらないので弊害はない。
続いて、図7を用いてメッセージキュー管理部11の動作を説明する。具体的には、トランザクションデータ受信時のキュー入出力管理部16の動作について説明する。
はじめに、キュー入出力管理部16は、クライアントアプリケーション1からトランザクションデータ18を受信する(ステップB01)。キュー入出力管理部16は、トランザクションデータID発行部19にトランザクションデータID14の払い出しを要求し、トランザクションデータIDを取得し、トランザクションデータ18に取得したトランザクションIDを設定する(ステップB02)。次に、キュー入出力管理部16は、「再送回数=0」の再送回数情報をトランザクションデータ18に設定し、トランザクションデータ18をメッセージキュー12に登録する(B03)。
続いて、図8を用いてメッセージキュー管理部11の動作を説明する。具体的には、トランザクションデータ送信時のキュー入出力管理部16の動作について説明する。
はじめに、キュー入出力管理部16は、キュー監視部22からトランザクションデータ18の送信要求を受け付ける(ステップC01)。次に、キュー入出力管理部16は、トランザクションデータ18の有無を確認する(ステップC02)。トランザクションデータ18がない場合は、キュー入出力管理部16は、トランザクションデータが存在しないことを示す情報をキュー監視部22へ出力する(ステップC03)。一方、トランザクションデータ18が存在する場合は、キュー入出力管理部16は、メッセージキュー12からトランザクションデータ18を取り出し、キュー監視部22へ送信する(ステップC04)。
キュー入出力管理部16がキュー監視部22へ送信したトランザクションデータ18には、トランザクションデータID14と再送回数情報15とが設定されている。キュー入出力管理部16は、キュー監視部22から出力される受信結果の応答を確認し(ステップC05)、正常に受信した旨の応答を得た場合には、当該トランザクションデータ18の再送回数に1を加算し、処理を終了する(ステップC06)。キュー入出力管理部16は、キュー監視部22から受信に失敗した旨の応答を得た場合には、ステップC04の処理を再度実行する。
続いて、図9を用いてメッセージキュー管理部11の動作を説明する。具体的には、トランザクションデータ18削除時のキュー入出力管理部16の動作について説明する。キュー入出力管理部16は、キュー監視部22から確認応答を受信すると(ステップD01)、メッセージキュー12から当該トランザクションデータID14のトランザクションデータ18を削除する(ステップD02)。
以上説明したように、本発明の実施の形態2にかかるトランザクション処理装置を用いることにより、次のような効果を得られる。
第1の効果は、非同期メッセージキューを用いたトランザクション処理プログラムの更新先リソースが1相コミット・リソースである場合にも、トランザクションデータの消失や2重処理を発生させることなくトランザクションを実行できる点にある。その理由は、再送回数とトランザクションデータID、トランザクション判断プログラムを利用することで処理すべきトランザクションデータなのか重複なのかを判断できるためである。
第2の効果は、更新先リソースがデータベースである必要がなく、ファイルシステム上の通常のファイルなどでもよい点にある。言い換えると、トランザクションデータIDを管理する管理テーブルと更新先リソースとの更新を同時に確定できなくてもよい点にある。その理由は、トランザクション判断プログラムを利用して、更新済みか未更新かを決定できる機構を備えているからである。
第3の効果は、業務アプリケーション内に、未処理や2重処理を防ぐための機構を実装する必要がない点にある。その理由は、トランザクションIDの採番・付与・検証やトランザクション判断プログラムにおける処理を業務アプリケーション(クライアントアプリケーションとサーバアプリケーション)から分離した構成としているからである。
第4の効果は、既に存在している非同期メッセージキューを用いた業務アプリケーションに本発明を適用することが容易であるという点がある。その理由は、本発明のトランザクション処理装置内のサーバアプリケーション以外の部品を用意しサーバアプリケーションをキュー監視部22から呼び出されるように配置し、かつ、クライアントアプリケーションのトランザクションデータ投入先を本発明のキュー入出力管理部16に変更すれば、容易に本発明の構成を実現できるからである。
第5の効果は、更新対象リソースが複数あってもよい点にある。その理由は、トランザクション処理装置は、管理テーブル中においてトランザクションデータID及びリソース番号ごとのステータスを管理し、全てのリソースの更新が完了できてから非同期メッセージキュー内のメッセージを削除する。これによって、更新漏れリソースが生じることを防ぎ、かつ、トランザクションデータの再受信時に管理テーブルとトランザクション判断プログラムを利用することによって重複を検出することができるからである。
(実施の形態3)
続いて、図10を用いて本発明の実施の形態3にかかるトランザクション処理装置2の構成例について説明する。図10においては、トランザクション処理装置2は、図2のキュー監視部22の代わりにメッセージ受信部32を有している。図2においては、キュー監視部22が、キュー入出力管理部16へ能動的に取得要求を出す方法、つまり、ポーリング(一定間間隔で取得要求を出す)によってトランザクションデータを取得する方法を示した。一方、図10に示すようにキュー入出力管理部16が主体となってトランザクションデータを送信してもよい。この場合には、メッセージ受信部32は、ポーリングによってトランザクションデータを受信するのではなく、キュー入出力管理部16から主体的に送信されたトランザクションデータを受信する。キュー入出力管理部16は、メッセージキュー12にトランザクションデータが格納されるたびにメッセージ受信部32へトランザクションデータを送信してもよく、定期的にメッセージキュー12に格納されているトランザクションデータをメッセージ受信部32へ送信してもよい。
以上説明したように、図10におけるトランザクション処理装置を用いることにより、トランザクション処理部21からメッセージキュー管理部11へ取得要求メッセージを送信する必要がなくなるため、トランザクション処理部21における処理を簡素化することが出来る。
(実施の形態4)
続いて、図11を用いて本発明の実施の形態4にかかるトランザクション処理装置2の構成例について説明する。メッセージキュー管理部11は、図2と同様であるため詳細な構成の説明を省略する。図11のトランザクション処理装置2は、複数の更新対象のリソースがある場合を示している。図11や下記の説明中では分かりやすくするためにリソースを2つにしているが、3つ以上あっても同様に実現できる。
ただし、図11においては、各リソースが必ず1回更新されることを保証できるが、全てのリソースの更新を同時に確定できる訳ではない。つまり、リソース1は更新されたがリソース2は更新されていない、という状態が発生しえる。
図11のトランザクション処理装置2は、メッセージ受信部32から呼び出されるサーバアプリケーションが1つではなく2つ存在する(サーバアプリケーション23_1及びサーバアプリケーション23_2)。また、トランザクション判断プログラム登録部26に登録されるプログラムがトランザクション判断プログラム27_1とトランザクション判断プログラム27_2との2つ存在する。その他の構成は図1や図9に示した構成と同等である。
続いて、図12を用いて本発明の実施の形態4にかかる管理テーブル24の構成例について説明する。図3に示した管理テーブル24と構成が異なり、図12の管理テーブル24には、「リソース番号」列が追加されている。この管理テーブル24では、主キーは、「トランザクションデータID」と「リソース番号」列の組になる。ステータス(状態)の値はそれぞれ以下を意味する。
・未実行:リソースは、該当のトランザクションデータを用いて更新されていない。
・実行中:リソースは、該当のトランザクションデータを用いて更新された可能性がある。
・完了:リソースは、該当のトランザクションデータを用いて更新された。
つまり、各行は、「各トランザクションデータIDを用いて各リソース更新処理を実行した状態が「未実行」か「実行中」か「完了」か」を意味する。「未実行」の場合は、メッセージ受信部32は、サーバアプリケーションを実行し、「実行中」の場合はトランザクション判断プログラムを実行しその結果次第でサーバアプリケーションを実行するか否かを決定する。「完了」の場合は、メッセージ受信部32は、トランザクションデータを廃棄する。
なお、リソース番号は、更新順ごとに登録するものとする。例えば、リソース番号1と2がある場合、リソース番号1の更新処理(23−1のサーバアプリケーション1の実行)の後、リソース番号2の更新処理(23−2のサーバアプリケーション2の実行)が行われる。
また、管理テーブル24の項目(カラム)は、本実施の形態4における動作の説明に必要な最低限のカラムだけを示している。実際には、管理テーブル24には、トランザクション判断プログラムの判断に利用できるように適宜項目が追加されてもよい。例えば、追加される項目として、トランザクションデータそのもの、再送回数、キュー入出力管理部16から受信した時刻などが考えられるがこの限りではない。
次に、図13を用いて、本実施例で使用されているトランザクション処理装置の動作を説明する。はじめに、図13のケース1となるフローについて解説する。
メッセージ受信部32は、キュー入出力管理部16からトランザクションデータ18を受信する(ステップY01)。次に、メッセージ受信部32は、トランザクションデータ18に付与されている再送回数情報を確認する(ステップY02)。再送回数が0の場合には、メッセージ受信部32は、トランザクションデータID管理部25に該当トランザクションデータID14の情報をリソースごとに新規登録する。この時、メッセージ受信部32は、リソース番号1を「ステータス=実行中」、リソース番号n(>1)のリソースを「ステータス=未実行」とする(ステップY14)。前述の通り、リソース番号は更新順ごととしているため、リソース番号1は最初に更新するリソースである。
次に、メッセージ受信部32は、処理対象リソース番号を表す変数nを「n=1」に設定する(ステップY15)。処理対象リソース番号を表す変数nを1とすることによって、ステップY09においてn=1のリソースが処理対象となる。そのため、メッセージ受信部22は、サーバアプリケーション23_1を呼び出し、サーバアプリケーション23_1は、リソース3_1を更新する。
メッセージ受信部32は、処理対象リソース番号を表す変数nが最後のリソースか判定を行う(ステップY10)。nが最後のリソースである場合には、メッセージ受信部32は、トランザクションデータID管理部25に該当トランザクションデータID14及びリソース番号nの情報を「ステータス=完了」に更新する(ステップY16)。さらに、メッセージ受信部32は、確認応答をキュー入出力管理部22へ出力する(ステップY13)。
ステップY10において、処理対象リソース番号を表す変数nが最後のリソースでないと判定された場合、メッセージ受信部32は、次のリソース番号の処理に移る。まず、メッセージ受信部32は、トランザクションデータID管理部25にトランザクションデータID及びリソース番号nの行を「ステータス=完了」に更新し、かつ、トランザクションデータID及びリソース番号n+1の情報を「ステータス=実行中」に更新する(ステップY11)。この2行の更新は、同一データベース内で行われるため同時に確定する。次に、処理対象リソース番号nに1を加算(ステップY12)し、ステップY09に戻る。この後、最後のリソースまで順次処理を繰り返す。
次に、図13のケース2となるフローについて説明する。ステップY02において、再送回数が0より大きいと判定された場合、管理テーブル24から該当トランザクションデータIDの情報を検索する(ステップY03)。キュー監視部22は、該当トランザクションデータIDが存在するかを確認し(ステップY04)、存在しない場合はケース1と同様に、当該トランザクションデータを処理すべきデータとみなした処理を行う。すなわち、ステップY14に遷移し、以降の処理を行う。
ケース2の処理を実行することにより、ケース1においてステップY14実行前、すなわち、特定のトランザクションデータを初めて処理するとき(再送回数=0)のステップY14実行前の時点(P01)に障害が発生した場合においても、正しく処理を行うことが出来る。つまり、P01において、トランザクション処理部21に障害が発生し、管理テーブル24に当該トランザクションデータIDのレコードを新規登録できなかった場合でも、メッセージ受信部32が該当のトランザクションデータを再取得した時に、トランザクションデータの消失や、サーバアプリケーション23においてトランザクションデータの2重処理が発生することなく正しく処理できることを可能としている。
ステップY04において、メッセージ受信部32は、該当トランザクションデータIDが存在すると判定した場合、管理テーブル24中の該当トランザクションデータIDの各リソース番号のステータス(状態)を確認する。メッセージ受信部32は、全てのリソース番号の行において「ステータス=完了」となっているかを確認する(ステップY05)。メッセージ受信部32は、全てのリソース番号の行において「ステータス=完了」となっていることを確認した場合(YESの場合)には、全リソースが該当トランザクションデータIDのトランザクションデータで更新済みであるので、トランザクションデータを破棄(ステップY17)し、確認応答をメッセージキューへ出力する(ステップY13)。ここで、ステップY05の判定がYESの場合をケース3とする。
ケース3により、最後のリソースに対してステップY09、Y10、Y16の処理完了後、すなわち、トランザクションの実行が正常に完了(ステップY09)し、管理テーブル24中の該当トランザクションデータIDの最後のリソース番号の行を「ステータス=完了」で更新した後の時点(P03)に障害が発生した場合においても正しく処理をすることが出来る。すなわち、P03においてトランザクション処理部21に障害が発生し、ステップY13の確認応答をメッセージキューへ出力できなかった場合に対処している。
また、ステップY13まで完了したがメッセージキュー管理部11内のキュー入出力管理部16の障害によってメッセージキュー12から該当トランザクションデータが削除できなかった場合や、ステップY13まで完了したがネットワーク障害などにより確認応答がキュー入出力管理部16に到達しなかった場合にも対処している。ここで言う対処とは、一連の処理が再度実行されステップY09つまりトランザクションの実行(リソースの更新処理)が重複して実行されてしまうことを回避できることを意味する。
続いて、ケース4となるフローについて説明する。ステップY05の判定において、「ステータス=実行中」であるリソースが存在する場合、そのリソース番号を取得し、処理対象リソース番号を表す変数nをその番号に設定する(ステップY06)。前述の通り、このリソースnはサーバアプリケーションnによる更新処理(ステップY09)が実行されたか否か判定できないので、メッセージ受信部32は、リソースn用のトランザクション判断プログラムnを実行する(ステップY07)。トランザクション判断プログラムnの結果が「重複」を示すかを判定し(ステップY08)、重複を示す場合には2重処理を防ぐためにサーバアプリケーションnの実行(ステップY09)は行わずに次のリソースの処理にうつる。すなわち、ステップY10にうつり、以降の処理を行う。「重複」ではなく「新規」を示す場合、サーバアプリケーションnによるトランザクション実行(リソースnの更新)後(ステップY09)、次のリソースの処理にうつる。
「ステータス=実行中」となっているリソースに関しては、リソースが更新済みなのか更新されていないのか判断ができないので、トランザクション判断プログラムで判断する。「ステータス=実行中」となりうるポイントについて以下に説明する。
・P02−1:Y14の完了後、かつ、Y09の完了前の時点。
ここでトランザクション処理装置2に障害が発生した場合、管理テーブル中のリソースn(n=1)の更新は完了していない。そのため、管理テーブル中の該当リソース番号(n=1)のステータスが「実行中」のままとなる。メッセージ受信部32が当該トランザクションデータIDのトランザクションデータを再度受信した時、ケース4の遷移となり、ステップY07においてリソースnに対するトランザクション判断プログラムが実行される。
・P02−2:Y09の完了後、かつ、ステップY11の完了前の時点、および、Y09の完了後、かつ、ステップY16の完了前の時点。
ここでトランザクション処理装置2に障害が発生した場合、リソースnの更新は完了しているが管理テーブル24中で該当リソース番号のステータスが「実行中」のままとなる。そのため、メッセージ受信部32が当該トランザクションデータIDのトランザクションデータを再度受信した時、ケース4の遷移となり、ステップY07においてリソースnに対するトランザクション判断プログラムが実行される。
・Point02−3:リソース番号nに対するY11の完了後、かつ、次のリソース番号(n=n+1)に対するY09の実行完了前の時点。
ここでトランザクション処理装置2に障害が発生した場合、リソースnの更新は完了し、リソースn+1の更新は完了していない。管理テーブル中のリソース番号nのステータスは「完了」、リソース番号n+1のステータスは「実行中」となっている。そのため、メッセージ受信部32が当該トランザクションデータIDのトランザクションデータを再度受信した時、ケース4の遷移となり、ステップY06では「ステータス=実行中」となっているリソース番号として(n+1)が取得される。よって、ステップY07においてリソースn+1に対するトランザクション判断プログラムn+1が実行される。
以上説明したように、本発明の実施の形態3にかかるトランザクション処理装置2を用いることにより、トランザクション処理装置2が複数のリソースを更新する場合においても、リソースの2重更新もしくはリソースの更新漏れ等を防ぐことが出来る。
上述の実施の形態では、本発明をハードウェアの構成として説明したが、本発明は、これに限定されるものではない。本発明は、図4及び図13におけるトランザクション処理装置の処理を、CPU(Central Processing Unit)にコンピュータプログラムを実行させることにより実現することも可能である。)
上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体(non-transitory computer readable medium)を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体(tangible storage medium)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体(例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ)、光磁気記録媒体(例えば光磁気ディスク)、CD−ROM(Read Only Memory)、CD−R、CD−R/W、半導体メモリ(例えば、マスクROM、PROM(Programmable ROM)、EPROM(Erasable PROM)、フラッシュROM、RAM(Random Access Memory))を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体(transitory computer readable medium)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。
(付記1)入力されたトランザクションデータを保持するメッセージキュー管理部と、前記トランザクションデータを用いてトランザクション処理を実行するトランザクション処理部と、を備え、前記メッセージキュー管理部は、前記トランザクションデータを前記トランザクション処理部へ出力した回数を示す再送回数を前記トランザクションデータと対応付けて管理し、前記トランザクション処理部は、前記メッセージキュー管理部から前記トランザクションデータとともに前記再送回数に関する情報を併せて取得し、前記再送回数に関する情報に再送が行われていないことを示す値が設定されている場合、前記トランザクション処理を実行する、トランザクション処理装置。
(付記2)前記トランザクション処理部は、前記トランザクションデータの前記トランザクション処理の状況を示すステータス情報を含む情報を管理する管理テーブルをさらに備え、前記トランザクション処理部は、前記トランザクションデータの再送回数に関する情報に、過去に前記トランザクションデータの再送を実行したことがあることを示す値が設定され、かつ、前記管理テーブルに前記トランザクションデータのステータス情報が管理されていない場合に前記トランザクション処理を実行する、付記1に記載のトランザクション処理装置。
(付記3)前記トランザクション処理部は、前記トランザクションデータの再送回数に関する情報に、過去に前記トランザクションデータの再送を実行したことがあることを示す値が設定され、かつ、前記管理テーブルに管理されている前記トランザクションデータのステータス情報がトランザクション処理の完了を示している場合、前記メッセージキュー管理部から取得した前記トランザクションデータを破棄する、付記2に記載のトランザクション処理装置。
(付記4)前記トランザクション処理部は、前記トランザクションデータの再送回数に関する情報に、過去に前記トランザクションデータの再送を実行したことがあることを示す値が設定され、かつ、前記管理テーブルに管理されている前記トランザクションデータのステータス情報がトランザクション処理の完了を示していない場合、前記トランザクション処理の内容に応じて前記トランザクション処理の実行もしくは不実行を判定するトランザクション判断プログラムに従い前記トランザクション処理を実行するか否かを判定する、付記2又は3に記載のトランザクション処理装置。
(付記5)前記トランザクション判断プログラムは、前記管理テーブルにおいて管理されている情報に基づいて、前記トランザクション処理を実行するか否かを判定する、付記4に記載のトランザクション処理装置。
(付記6)前記トランザクション判断プログラムは、前記メッセージキュー管理部から取得した前記トランザクションデータが生成された時刻情報が、前記管理テーブルに記録されたトランザクションデータが生成された時刻情報よりも新しい場合、前記トランザクション処理を実行する、付記4又は5に記載のトランザクション処理装置。
(付記7)前記トランザクション処理部は、前記メッセージキュー管理部へトランザクションデータの送信要求メッセージを送信した後に前記トランザクションデータを前記メッセージキュー管理部から取得する、付記1乃至6のいずれか1項に記載のトランザクション処理装置。
(付記8)前記メッセージキュー管理部は、前記トランザクションデータを保持すると、前記トランザクションデータを前記トランザクション処理部へ出力し、前記トランザクション処理部は、前記メッセージキュー管理部から出力された前記トランザクションデータを取得する、付記1乃至6のいずれか1項に記載のトランザクション処理装置。
(付記9)トランザクションデータを出力するクライアントアプリケーションと、前記出力されたトランザクションデータを保持するメッセージキュー管理部と、前記トランザクションデータを用いてトランザクション処理を実行するトランザクション処理部と、を有するトランザクション処理装置と、前記トランザクション処理が実行されることにより更新されるリソースを保持するデータ格納装置と、を備えるトランザクション処理システムであって、前記メッセージキュー管理部は、前記トランザクションデータを前記トランザクション処理部へ出力した回数を示す再送回数を前記トランザクションデータと対応付けて管理し、前記トランザクション処理部は、前記メッセージキュー管理部から前記トランザクションデータとともに前記再送回数に関する情報を併せて取得し、前記再送回数に関する情報に再送が行われていないことを示す値が設定されている場合、前記トランザクション処理を実行する、トランザクション処理システム。
(付記10)入力されたトランザクションデータを保持し、前記トランザクションデータを用いてトランザクション処理を実行するトランザクション処理部へ、前記トランザクションデータを出力した回数を示す再送回数を前記トランザクションデータに設定し、
前記再送回数に関する情報に再送が行われていないことを示す値が設定されている場合、前記トランザクションデータを用いて前記トランザクション処理を実行する、トランザクション処理方法。
(付記11)入力されたトランザクションデータを保持するステップと、前記トランザクションデータを用いてトランザクション処理を実行するトランザクション処理部へ、前記トランザクションデータを出力した回数を示す再送回数を前記トランザクションデータに設定するステップと、前記再送回数に関する情報に再送が行われていないことを示す値が設定されている場合、前記トランザクションデータを用いて前記トランザクション処理を実行するステップと、をコンピュータに実行させるプログラム。