JP6171494B2 - 情報処理装置、処理要求プログラム、および処理要求方法 - Google Patents

情報処理装置、処理要求プログラム、および処理要求方法 Download PDF

Info

Publication number
JP6171494B2
JP6171494B2 JP2013074295A JP2013074295A JP6171494B2 JP 6171494 B2 JP6171494 B2 JP 6171494B2 JP 2013074295 A JP2013074295 A JP 2013074295A JP 2013074295 A JP2013074295 A JP 2013074295A JP 6171494 B2 JP6171494 B2 JP 6171494B2
Authority
JP
Japan
Prior art keywords
processing
resource
success rate
request
devices
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.)
Expired - Fee Related
Application number
JP2013074295A
Other languages
English (en)
Other versions
JP2014199534A (ja
Inventor
良男 古森
良男 古森
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2013074295A priority Critical patent/JP6171494B2/ja
Publication of JP2014199534A publication Critical patent/JP2014199534A/ja
Application granted granted Critical
Publication of JP6171494B2 publication Critical patent/JP6171494B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明は、複数の装置に処理要求を送信する情報処理装置、処理要求プログラム、および処理要求方法に関する。
コンピュータで実行される処理として、トランザクションがある。トランザクションは、複数の処理を1つの処理単位としてまとめたものである。トランザクションでは、実行するすべての処理について、すべて成功するか、すべて失敗するかのいずれかになることが保証される。
トランザクションのなかには、複数のリソースを操作するものがある。ここでリソースとは、データベースやサービスである。またトランザクションで操作されるリソースには、例えばThe Open Groupの「Distributed Transaction Processing : The XA Specification」の仕様に規定されているリソースマネージャで提供されるリソースも含まれる。
複数のリソースを操作するトランザクションでは、それらのリソースの内容の整合性を保つために、例えば2フェーズコミットと呼ばれる技術が用いられる。2フェーズコミットでは、トランザクションを実行するコンピュータは、各リソースを提供するサーバの準備確認を行う。準備確認では、トランザクションを実行するコンピュータは、リソースを提供するサーバに対して、リソースの更新が可能かどうかを問い合わせる。各サーバは、その問い合わせに応じて更新準備を行い、準備が完了すると、準備完了を応答する。トランザクションを実行するコンピュータは、リソースを提供するすべてのサーバからの準備完了の応答を確認すると、各サーバに対して操作反映(コミット)を指示する。各サーバは、操作反映の指示に応じて、リソースの内容を更新する。操作反映が不可能なリソースが1つでも存在する場合は、トランザクションを実行するコンピュータは、リソースを管理するすべてのサーバに対して、リソース操作の取り消し(ロールバック)を指示する。
2フェーズコミットに関する技術としては、例えば、計算機間の通信ネットワークを経由したメッセージの送信回数が最小となる経路でコミット制御メッセージを送信する技術が考えられている。
特開平6−259388号公報
しかし、2フェーズコミットでは、リソースを提供する複数のサーバそれぞれへの、準備確認や操作反映のメッセージを送信する順番について考慮されていない。そのため、非効率的な順番でメッセージが送信され、全体の処理時間を長期化させるおそれがある。なお、2フェーズコミットに限らず、複数の装置に処理要求を送信し、各装置からの応答を待つ技術であれば、効率の悪い順番で処理要求が送信されると、処理時間が長期化する。
1つの側面では、本件は、複数の装置に実行させる処理の効率化を図ることを目的とする。
1つの案では、決定手段と制御手段とを有する情報処理装置が提供される。決定手段は、並列に処理を実行させる複数の装置のうち、処理に要する時間が所定値より長い装置への処理要求が、他の装置よりも先に送信されるように、複数の装置への処理要求の送信順を決定する。制御手段は、該送信順で、複数の装置それぞれに対して処理要求を送信し、複数の装置に並列に処理を実行させる。
1態様によれば、複数の装置に処理を効率的に実行させることが可能となる。
第1の実施の形態に係るシステムの一例を示す図である。 第2の実施の形態のシステム構成例を示す図である。 第2の実施の形態に用いるアプリケーションサーバのハードウェアの一構成例を示す図である。 第2の実施の形態を実現するための機能を示すブロック図である。 リソース統計情報記憶部のデータ構造の一例を示す図である。 トランザクションの手順の一例を示すシーケンス図である。 処理時間によるリソース一覧の並べ替えの一例を示す図である。 成功率に基づくリソース一覧の並べ替えの第1の例を示す図である。 成功率に基づくリソース一覧の並べ替えの第2の例を示す図である。 順番判定処理の手順の一例を示す図である。 コミット処理の第1の例を示す図である。 コミット処理の第2の例を示す図である。
以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第1の実施の形態〕
図1は、第1の実施の形態に係るシステムの一例を示す図である。第1の実施の形態では、情報処理装置10がネットワーク4を介して複数の装置1〜3に接続されている。情報処理装置10は、複数の装置1〜3それぞれに対して、処理要求を送信し、処理を実行させることができる。情報処理装置10は、複数の装置1〜3に処理を実行させるために、記憶手段11、決定手段12、および制御手段13を有する。
記憶手段11は、複数の装置1〜3の処理に要する時間に関する統計情報11aを記憶する。
決定手段12は、複数の装置1〜3のうち、処理に要する時間(処理時間)が所定値より長い装置への処理要求が、他の装置よりも先に送信されるように、処理要求の送信順を決定する。例えば決定手段12は、統計情報11aを参照し、複数の装置1〜3それぞれの処理時間を認識する。そして、決定手段12は、処理に要する時間が長いほど処理要求が先に送信されるように、送信順を決定することができる。また決定手段12は、処理時間が長いほど上位となる複数の等級(ランク)を設け、並列に処理を実行させる複数の装置1〜3それぞれについて、処理時間に基づいて等級を決定することもできる。等級としては、例えば処理時間が「長い」、「普通」、「短い」の3等級とすることができる。そして決定手段12は、等級が上位の装置ほど処理要求が先に送信されるように送信順を決定する。また決定手段12は、装置によって処理が実行されるごとに、その装置の処理に要する時間に関する統計情報11aを更新することもできる。
制御手段13は、決定手段12で決定された送信順で、複数の装置1〜3それぞれに対して処理要求を送信し、複数の装置1〜3に並列に処理を実行させる。
このようなシステムによれば、情報処理装置10の決定手段12により、複数の装置1〜3それぞれに対し、処理時間が長い装置から順に処理要求を送信するように、処理要求の送信順が決定される。例えば統計情報11aに、各装置1〜3の処理時間が設定されている。図1の例では、装置1の処理時間「t1」、装置2の処理時間「t2」、装置3の処理時間「t3」との関係が、「t2<t1<t3」である(t1,t2,t3は、正の実数)。この場合、決定手段12は、例えば統計情報11aを参照し、各装置1〜3の処理時間を比較する。そして決定手段12は、処理時間が最も長い装置3を、処理要求の送信順の1番目に決定し、処理時間が2番目に長い装置1を、処理要求の送信順の2番目に決定し、処理時間が最も短い装置2を、処理要求の送信順の3番目に決定する。決定手段12は、決定した送信順を、制御手段13に通知する。
制御手段13は、決定された送信順で、複数の装置1〜3それぞれに処理要求を送信する。図1の例では、最初に装置3に対して処理要求を送信し、次に装置1に対して処理要求を送信し、最後に装置2に対して処理要求を送信する。なお制御手段13は、装置1〜3に並列に処理を実行させる。すなわち制御手段13は、先に送信した処理要求に対する結果の応答を待たずに、次の処理要求を送信する。
制御手段13が送信した処理要求は、ネットワーク4を介して複数の装置1〜3それぞれに送られる。処理要求を受信した複数の装置1〜3それぞれは、処理要求に応じて処理を実行する。そして複数の装置1〜3それぞれは、処理が終了すると、処理結果を情報処理装置10に応答する。
これにより、情報処理装置10は、処理要求を他の送信順で送信した場合に比べて効率的に処理が行われる。その結果、短い時間で、すべての装置1〜3からの応答を受信することができる。
例えば、処理時間の短い装置2から順に処理要求を送信した場合、処理要求の送信間隔の分だけ、他の装置1,3への処理要求の送信が遅れる。すると、最も処理時間が長い装置3への処理要求の送信が遅れ、装置3から処理結果の応答を受信するのも遅れることとなる。それに対し、請求項1に示すように、最も処理時間が長い装置3への処理要求を最初に送信することで、装置3からの応答を、可能な限り早く受信することができる。しかも他の装置1,2は、装置3よりも処理時間が短いため、装置3からの応答の送信より前に、装置1,2からの応答の送信が期待できる。すなわち装置3に最初に処理要求を送信し、処理を迅速に開始させることで、複数の装置1〜3に対して処理を並列で実施させた場合において、すべての装置1〜3で処理が完了するまでの所要時間が短縮される。
しかも処理要求がネットワーク4を介して転送される場合、ネットワーク4の負荷状況に応じて、処理要求の転送の遅延時間も変化する。ネットワーク4上で通信を中継する装置は、情報を受信した順に転送するため、処理要求を短い時間間隔で連続して送信しても、送信が後の処理要求は、前の処理要求よりも転送の遅延時間が長くなる可能性がある。そこで第1の実施の形態では、処理時間が長い装置3への処理要求を最初に送信することで、装置3への処理要求が他の装置1,2への処理要求よりも優先して転送されるようにし、全体としての処理の遅延を抑止している。
なお決定手段12は、並列に処理を実行させる複数の装置1〜3の処理時間の平均からの、複数の装置1〜3それぞれの処理時間のかい離率に基づいて、複数の装置1〜3それぞれの等級を決定するようにしてもよい。例えば決定手段12は、複数の装置1〜3の処理時間の平均からの、複数の装置1〜3それぞれの処理時間のかい離率を計算し、処理時間のかい離率が閾値より大きい装置を、処理時間が所定値より長い装置とする。この場合、かい離率が閾値となる処理時間が、処理時間の所定値である。処理時間の平均からのかい離率を用いることで、並列で処理を実行する装置の処理時間の相対的な関係により、処理時間の長さの等級を決定できる。その結果、並列に処理を実行させる装置の組み合わせに応じた適切な階級分けを行うことができる。
また決定手段12は、例えば複数の装置1〜3それぞれで提供されるリソースを更新するトランザクションの実行時に、送信順を決定することができる。その場合、制御手段13は、トランザクションの結果を複数の装置1〜3それぞれに確定させる処理要求を、複数の装置1〜3それぞれに送信する。トランザクションの結果を確定させる処理は、コミットと呼ばれる。コミットを効率的に行うことで、トランザクションの処理の効率化を図ることができる。
なおコミットとしては、例えば2フェーズコミットの技術を用いることができる。この場合、制御手段13は、2フェーズコミットのリソース操作の処理要求(準備確認の処理要求、または操作反映確定の処理要求)を、決定手段12が決定した送信順に従って送信する。これにより、2フェーズコミットを効率的に実行することができる。
また決定手段12は、トランザクションで更新されるリソースを提供する複数の装置1〜3のうちの一部のみを、並列に処理を実行させる装置とすることができる。例えば決定手段12は、処理の成功率が所定の成功率判定値未満であり、かつ処理時間が所定の処理時間判定値未満の装置を特定する。そして決定手段12は、複数の装置1〜3から特定した装置を除いた装置を、並列に処理を実行させる複数の装置に決定する。この場合、制御手段13は、特定した装置に対して先行して処理要求を送信する。制御手段13は、先行して処理要求を送信した装置から処理が正常したことを示す応答を受信した後、並列に処理を実行させる複数の装置それぞれに対して処理要求を送信する。これにより、成功率が悪い装置で処理に失敗した場合、他の装置に無駄な処理を行わせずにすみ、処理失敗時の処理効率が向上する。なお先行して処理要求を送信する装置は、処理時間が短いため、その装置からの正常の応答を待ってから、他の装置に処理要求を送信しても、処理の遅延は少なくてすむ。
また決定手段12は、トランザクションで更新されるリソースを提供する複数の装置における処理の平均の成功率からの、複数の装置それぞれの成功率のかい離率を計算し、成功率のかい離率が閾値未満の装置を、処理の成功率が所定値未満の装置と判断することができる。このように、複数の装置の処理の平均の成功率からのかい離率を用いることで、複数の装置の処理の成功率の相対的な関係により、処理の成功率が所定値未満の装置を特定できる。その結果、トランザクションの処理を行う装置の組み合わせに応じた適切な装置を、処理の成功率が所定値以下の装置とすることができる。
なお図1に示す決定手段12、制御手段13は、例えば情報処理装置10が有するプロセッサにより実現することができる。また、記憶手段11は、例えば情報処理装置10が有するメモリにより実現することができる。
また図1に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。
〔第2の実施の形態〕
次に第2の実施の形態について説明する。第2の実施の形態は、アプリケーションソフトウェアの実行時に行われるトランザクションを効率的に行うものである。
図2は、第2の実施の形態のシステム構成例を示す図である。アプリケーションサーバ100には、ネットワーク20を介して、端末装置30や、複数のサーバ210,220,230,・・・が接続されている。アプリケーションサーバ100は、アプリケーションソフトウェアを実行する。例えばアプリケーションサーバ100は、端末装置30からの要求に応じて、アプリケーションソフトウェアを実行する。
サーバ210,220,230,・・・は、各種のリソースをアプリケーションサーバ100に提供する。提供されるリソースは、データベースやその他のサービス機能である。アプリケーションサーバ100は、サーバ210,220,230,・・・で提供されるリソースを利用したトランザクションを行うことができる。アプリケーションソフトウェアに基づいて実行する処理には、例えばサーバ210,220,230,・・・で提供されるリソースの更新を含むトランザクションがある。
アプリケーションサーバ100は、複数のリソースを更新するトランザクションを実行する場合、操作対象のリソースを提供する複数のサーバに対して、処理要求を送信する。そしてアプリケーションサーバ100は、例えば2フェーズコミットによって、トランザクションの結果の整合性を担保する。アプリケーションサーバ100は、2フェーズコミットにおける調整者(coordinator)であり、操作対象のリソースを管理するサーバは参加者(cohorts)である。トランザクションを実行する場合、アプリケーションサーバ100は、効率的に処理できるように、処理要求の送信先のサーバの順番を決定する。そしてアプリケーションサーバ100は、決定した順番で、サーバに処理要求を送信する。これにより、トランザクションの効率化を図ることができる。
図3は、第2の実施の形態に用いるアプリケーションサーバのハードウェアの一構成例を示す図である。アプリケーションサーバ100は、プロセッサ101によって装置全体が制御されている。プロセッサ101には、バス109を介してメモリ102と複数の周辺機器が接続されている。プロセッサ101は、マルチプロセッサであってもよい。プロセッサ101は、例えばCPU(Central Processing Unit)、MPU(Micro Processing Unit)、またはDSP(Digital Signal Processor)である。プロセッサ101の機能の少なくとも一部を、ASIC(Application Specific Integrated Circuit)、PLD(Programmable Logic Device)などの電子回路で実現してもよい。
メモリ102は、アプリケーションサーバ100の主記憶装置として使用される。メモリ102には、プロセッサ101に実行させるOS(Operating System)のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ102には、プロセッサ101による処理に必要な各種データが格納される。メモリ102としては、例えばRAM(Random Access Memory)などの揮発性の半導体記憶装置が使用される。
バス109に接続されている周辺機器としては、HDD(Hard Disk Drive)103、グラフィック処理装置104、入力インタフェース105、光学ドライブ装置106、機器接続インタフェース107およびネットワークインタフェース108がある。
HDD103は、内蔵したディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。HDD103は、アプリケーションサーバ100の補助記憶装置として使用される。HDD103には、OSのプログラム、アプリケーションプログラム、および各種データが格納される。なお、補助記憶装置としては、フラッシュメモリなどの不揮発性の半導体記憶装置を使用することもできる。
グラフィック処理装置104には、モニタ21が接続されている。グラフィック処理装置104は、プロセッサ101からの命令に従って、画像をモニタ21の画面に表示させる。モニタ21としては、CRT(Cathode Ray Tube)を用いた表示装置や液晶表示装置などがある。
入力インタフェース105には、キーボード22とマウス23とが接続されている。入力インタフェース105は、キーボード22やマウス23から送られてくる信号をプロセッサ101に送信する。なお、マウス23は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。
光学ドライブ装置106は、レーザ光などを利用して、光ディスク24に記録されたデータの読み取りを行う。光ディスク24は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク24には、DVD(Digital Versatile Disc)、DVD−RAM、CD−ROM(Compact Disc Read Only Memory)、CD−R(Recordable)/RW(ReWritable)などがある。
機器接続インタフェース107は、アプリケーションサーバ100に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース107には、メモリ装置25やメモリリーダライタ26を接続することができる。メモリ装置25は、機器接続インタフェース107との通信機能を搭載した記録媒体である。メモリリーダライタ26は、メモリカード27へのデータの書き込み、またはメモリカード27からのデータの読み出しを行う装置である。メモリカード27は、カード型の記録媒体である。
ネットワークインタフェース108は、ネットワーク20に接続されている。ネットワークインタフェース108は、ネットワーク20を介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。
以上のようなハードウェア構成によって、第2の実施の形態の処理機能を実現することができる。なお、第1の実施の形態に示した情報処理装置10も、図3に示したアプリケーションサーバ100と同様のハードウェアにより実現することができる。
アプリケーションサーバ100は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第2の実施の形態の処理機能を実現する。アプリケーションサーバ100に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、アプリケーションサーバ100に実行させるプログラムをHDD103に格納しておくことができる。プロセッサ101は、HDD103内のプログラムの少なくとも一部をメモリ102にロードし、プログラムを実行する。またアプリケーションサーバ100に実行させるプログラムを、光ディスク24、メモリ装置25、メモリカード27などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ101からの制御により、HDD103にインストールされた後、実行可能となる。またプロセッサ101が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。
図4は、第2の実施の形態を実現するための機能を示すブロック図である。サーバ210は、リソースとしてデータベースシステム211を有している。データベースシステム211は、サーバ210がソフトウェアを実行することで実現される。データベースシステム211は、データを管理しており、アプリケーションサーバ100からの要求に応じてデータを更新する。
サーバ220は、リソースとしてメッセージングシステム221を有している。メッセージングシステム221は、サーバ220がソフトウェアを実行することで実現される。メッセージングシステム221は、ユーザに通知するメッセージを管理する。例えばメッセージングシステム221は、アプリケーションサーバ100からの要求に応じて、メッセージを更新する。
サーバ230は、リソースとしてエンタープライズ情報システム(EIS:Enterprise Information System)231を有している。エンタープライズ情報システム231は、サーバ230がソフトウェアを実行することで実現される。エンタープライズ情報システム231は、企業の業務を行う情報処理システムである。エンタープライズ情報システム231は、アプリケーションサーバ100からの要求に応じて、業務に関する情報を更新する。
アプリケーションサーバ100は、アプリケーション110とトランザクション制御部120とを有する。アプリケーション110は、アプリケーションサーバ100がアプリケーションソフトウェアを実行することで実現される。アプリケーション110は、処理の実行過程で、ネットワーク20を介して接続されたサーバで提供されるリソースの内容を更新する処理が発生すると、そのリソースのトランザクションによる操作の要求を送信する。
トランザクション制御部120は、アプリケーション110からの、トランザクションに関する処理要求に応じて、2フェーズコミットによるトランザクションを実行する。トランザクションを実行するために、トランザクション制御部120は、処理要求管理部121、順番判定部122、および通信制御部123を有する。
処理要求管理部121は、アプリケーション110からの処理要求を取得し、順番判定部122に、リソースへの要求の送信順の判定を依頼する。処理要求管理部121は、順番判定部122からリソースを提供するサーバへの要求の送信順を受け取ると、その順番でのリソースへの処理要求の送信を、通信制御部123に通知する。そして処理要求管理部121は、通信制御部123から処理結果を受け取ると、その処理結果をアプリケーション110に通知する。
順番判定部122は、リソースを提供するサーバへの要求の送信順を判定する。例えば順番判定部122は、処理に要する時間が長いリソースへの要求ほど、先に送信するように、順番を判定する。順番判定部122は、順番を判定するために、リソース統計情報記憶部122a、リソース統計情報更新部122b、およびリソース統計情報解析部122cを有する。
リソース統計情報記憶部122aは、トランザクション中でのリソースの更新に関する統計情報(リソース統計情報)を記憶する。リソース統計情報には、例えば更新処理の平均の所要時間が含まれる。リソース統計情報記憶部122aとしては、例えばメモリ102またはHDD103の記憶領域の一部が使用される。
リソース統計情報更新部122bは、リソース統計情報を算出し、リソース統計情報記憶部122a内のリソース統計情報を更新する。例えばリソース統計情報更新部122bは、トランザクションが実行されるごとに、リソース統計情報を更新する。
リソース統計情報解析部122cは、リソース統計情報記憶部122aに格納されているリソース統計情報を解析し、トランザクションで更新される複数のリソースそれぞれを有するサーバへの、要求の送信順を決定する。リソース統計情報解析部122cは、決定した送信順を、処理要求管理部121に通知する。
通信制御部123は、処理要求管理部121から、トランザクションに関する要求の送信の通知を受け取ると、その要求を、トランザクションで更新されるリソースを有するサーバに送信する。この際、通信制御部123は、処理要求管理部121から指示された順番で要求を送信する。通信制御部123は、要求に対する結果の応答を各サーバから受信すると、処理結果を処理要求管理部121に通知する。
このような機能を有するシステムにより、トランザクションを効率的に実行することができる。なお、図4に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。また図4に示すリソース統計情報記憶部122aは、図1に示す第1の実施の形態の記憶手段11の一例である。図4に示す順番判定部122は、図1に示す第1の実施の形態の決定手段12の一例である。図4に示す通信制御部123は、図1に示す第1の実施の形態の制御手段13の一例である。
次にリソース統計情報記憶部122aに格納されるリソース統計情報について詳細に説明する。
図5は、リソース統計情報記憶部のデータ構造の一例を示す図である。図5の例では、リソース統計情報記憶部122aには、データテーブル形式のリソース統計情報32が格納されている。リソース統計情報32には、リソース、場所、トランザクション回数、成功回数、処理時間、および成功率の欄が設けられている。
リソースの欄には、リソースの識別情報が設定される。図5の例では、リソースの欄に、リソースの名称が設定されている。
場所の欄には、リソースの提供場所が設定される。リソースの提供場所としては、例えばリソースが操作しているサーバのアドレス、そのサーバ内でのリソースの場所が設定される。サーバ内でのリソースの場所は、例えばディレクトリパスとファイル名とで表される。
トランザクション回数の欄には、トランザクションによってリソースに対して行われた更新処理の回数が設定される。
成功回数の欄には、トランザクションによってリソースに対して行われた更新処理のうち、成功終了した回数が設定される。
処理時間の欄には、トランザクションにおけるリソース更新に関する要求に応じた処理に要した時間の平均が設定される。
成功率の欄には、トランザクションにおけるリソース更新に関する要求に応じた処理の成功率が設定される。
このようなリソース統計情報32を用いて、トランザクションが効率的に実行される。以下、トランザクションの手順について詳細に説明する。
図6は、トランザクションの手順の一例を示すシーケンス図である。まずアプリケーション110が、トランザクション制御部120に対して、トランザクションの開始を通知する(ステップS11)。トランザクションの開始の通知を受け取ったトランザクション制御部120は、トランザクションの制御を開始する(ステップS12)。
次にアプリケーション110は、トランザクションにおいて更新する複数のリソースそれぞれに対して、リソース更新操作を行うこと通知する(ステップS13)。図6の例では、データベースシステム211、メッセージングシステム221、およびエンタープライズ情報システム231が操作対象のリソースであり、これらのリソースに、リソース更新操作を行うことが通知されている。例えばデータベースシステム211に対するSQL(Structured Query Language)文の発行や、メッセージングシステム221へのメッセージ送受信などが行われる。
このとき、トランザクション制御部120は、アプリケーション110から各リソースへの通知を監視し、どのリソースに対して通知が行われたのかを認識する。そしてトランザクション制御部120は、操作対象のリソースを記憶する(ステップS14)。
続いて、アプリケーション110は、トランザクション制御部120へ、操作反映を通知する(ステップS15)。トランザクション制御部120は、アプリケーション110からの操作反映の通知を受け取ると、ステップS14で記憶しておいた操作対象のリソース一覧を、順番判定部122へ通知する(ステップS16)。
順番判定部122は、操作対象のリソース一覧を受信すると、リソース統計情報に基づいて、操作対象のリソースそれぞれの、要求に対する平均処理時間を比較する。また順番判定部122は、処理の成功率に基づいて、各リソースにおける処理の成功率の善し悪しを判断する。そして順番判定部122は、平均処理時間の比較結果と、成功率の善し悪しとに基づいて、要求を送信するリソースの順番を判定する(ステップS17)。例えば順番判定部122は、リソース統計情報記憶部122a内のリソース統計情報32を参照し、受信した操作対象のリソース一覧を、処理時間が長いリソースほど上位となるように並べ替える。リソース一覧の上位に登録されたリソースほど、先に要求を送信するリソースであることを示している。また順番判定部122は、処理時間が短いが、成功率が悪いリソースがある場合、そのリソースを一覧の最上位に移動し、他のリソースよりも先に要求を送信するように、送信順を判定することもできる。要求の送信順を判定すると、順番判定部122は、判定した順番を示すリソース一覧を、トランザクション制御部120に通知する(ステップS18)。
トランザクション制御部120は、順番判定部122から要求の送信順を示すリソース一覧を取得する(ステップS19)。そしてトランザクション制御部120は、取得した一覧の上位のリソースほど処理要求の送信が先となるように送信順を指定して、操作反映依頼を通信制御部123に送信する(ステップS20)。
通信制御部123は、操作反映依頼に従って、操作反映処理を並列処理で実施する。なお並列処理であっても、要求の送信は順番に行うこととなる。そこで通信制御部123は、操作反映依頼で指定された送信順で、各リソースへ準備確認の要求を送信する(ステップS21)。
準備確認の要求を受信したデータベースシステム211、メッセージングシステム221、およびエンタープライズ情報システム231は、2フェーズコミットにおける操作反映の準備をする。操作反映の準備とは、リソースの更新(コミット)を行える状態まで、処理を進めることである。このとき実施した処理を取り消すことができるように、実施した処理の履歴が、各リソースにおいて記録される。データベースシステム211、メッセージングシステム221、およびエンタープライズ情報システム231は、それぞれ操作反映の準備が完了すると、通信制御部123へ準備状況を応答する(ステップS22,S23,S24)。
通信制御部123は、各リソースからの準備状況の応答を受信し、操作対象のすべてのリソースにおいて操作準備が正常に完了したことを確認する。そして通信制御部123は、操作反映依頼で指定された送信順で、各リソースに操作反映確定の要求を送信する(ステップS25)。
操作反映確定の要求を受信したデータベースシステム211、メッセージングシステム221、およびエンタープライズ情報システム231は、2フェーズコミットにおける操作反映の確定処理(コミット)を実行する。そしてデータベースシステム211、メッセージングシステム221、およびエンタープライズ情報システム231は、それぞれコミット完了の応答を、通信制御部123へ送信する(ステップS26,S27,S28)。
通信制御部123は、各リソースからコミット完了の応答を受信すると、操作反映処理の結果をトランザクション制御部120に通知する(ステップS29)。トランザクション制御部120は、操作反映処理の結果を順番判定部122とアプリケーションに110に通知する(ステップS30)。なお順番判定部122への結果の通知には、例えば処理時間、処理結果などの情報が含まれる。
順番判定部122は、結果の通知内容に応じて、リソース統計情報記憶部122a内のリソース統計情報32を更新する(ステップS31)。例えば順番判定部122のリソース統計情報更新部122bは、操作対象の各リソースのトランザクション回数を1ずつカウントアップする。またリソース統計情報更新部122bは、操作反映が成功したリソースの成功回数を、1ずつカウントアップする。さらにリソース統計情報更新部122bは、今回の操作反映の処理時間に基づいて、各リソースの処理時間を更新する。例えばリソース統計情報更新部122bは、リソースのカウントアップ前のトランザクション回数と処理時間を乗算し、乗算結果に今回の処理時間を加算する。そしてリソース統計情報更新部122bは、加算結果を、カウントアップ後のトランザクション回数で除算する。除算結果が、更新後の処理時間となる。またリソース統計情報更新部122bは、各リソースの成功率を計算する。例えばリソース統計情報更新部122bは、カウントアップ後の成功回数を、カウントアップ後のトランザクション回数で除算する。そしてリソース統計情報更新部122bは、除算結果を、そのリソースの成功率とする。
アプリケーション110は、トランザクション制御部120から処理結果を受信する(ステップS32)。アプリケーション110は、通知された処理結果に応じて以降の業務処理を継続する。
このような手順でトランザクションが実行される。そして第2の実施の形態では、各リソースへ操作反映を並列処理で実行する際に、高速に処理が実行できるような適切な順番で、リソースに要求を送信する。
高速に処理が実行できる順番は、リソース統計情報解析部122cによって判定される。例えばリソース統計情報解析部122cは、リソース一覧33に含まれる各リソースの処理時間および成功率を解析し、処理時間が最短となる処理順番を決定する。そしてリソース統計情報解析部122cは、処理順番が早い順となるように、リソース一覧を並べ替える。
例えばリソース統計情報解析部122cは、まず、処理時間によってリソース一覧の並べ替えを行う。
図7は、処理時間によるリソース一覧の並べ替えの一例を示す図である。例えばリソース統計情報解析部122cは、まず操作対象のリソースの処理時間を評価する。処理時間の評価は、例えば「短い」、「普通」、「長い」の3段階で行われる。3段階で処理時間を評価する場合、「短い」と判定するための閾値(第1の時間閾値)と、「長い」と判定するための閾値(第2の時間閾値)とが設けられる。処理時間が第1の時間閾値より短いリソースは、処理時間が「短い」と評価される。処理時間が第2の時間閾値より長いリソースは、処理時間が「長い」と評価される。処理時間が第1の時間閾値から第2の時間閾値までの範囲に含まれるリソースは、処理時間が「普通」と評価される。
処理時間の閾値は、操作対象の各リソースの処理時間の平均値とのかい離率に基づいて設定することもできる。例えばリソース統計情報解析部122cは、操作対象の各リソースの処理時間の平均値を計算する。そしてリソース統計情報解析部122cは、例えば操作対象のリソースの処理時間から平均値を減算し、減算結果を平均値で除算する。リソース統計情報解析部122cは、除算結果を、処理時間のかい離率とする。リソース統計情報解析部122cは、処理時間のかい離率の閾値と、各リソースの処理時間のかい離率とを比較して、処理時間を評価する。
処理時間のかい離率の閾値としては、例えば「短い」と判定するための閾値と、「長い」と判定するための閾値との2つを予め設定しておく。また、1つのかい離率の閾値で、処理時間を3段階に評価することもできる。例えばリソース統計情報解析部122cは、リソースの処理時間のかい離率の絶対値が、処理時間のかい離率の閾値より大きく、かつそのリソースの処理時間のかい離率が正の値の場合、処理時間が「長い」と評価する。またリソース統計情報解析部122cは、リソースの処理時間のかい離率の絶対値が、処理時間のかい離率の閾値より大きく、かつそのリソースの処理時間のかい離率が負の値の場合、処理時間が「短い」と評価する。さらにリソース統計情報解析部122cは、リソースの処理時間のかい離率の絶対値が、処理時間のかい離率の閾値以下であれば、処理時間が「普通」であると評価する。
なお、具体的な処理時間のかい離率の閾値は、運用形態やマシンスペックなどに応じて、任意に設定できる。
図7の例では、「リソースB」の処理時間が最も短く、その次に「リソースA」の処理時間が短く、「リソースC」の処理時間が最も長い。リソース統計情報解析部122cは、リソース一覧33に登録されている各リソースを、処理時間が長いほど上位となるようにソートする。すると、ソート後のリソース一覧33では、「リソースC」が最も上位となり、その次に「リソースA」が配置され、最下位に「リソースB」が配置される。
ここで、ソート後のリソース一覧33に示される順番を、そのまま要求の送信順とすることができる。また、操作反映処理の成功率に基づいて、順番を入れ替えることもできる。
図8は、成功率に基づくリソース一覧の並べ替えの第1の例を示す図である。例えばリソース統計情報解析部122cは、リソース一覧33に含まれる各リソースの成功率を評価する。成功率の評価は、例えば「悪い」か「良い」かの2段階で行われる。2段階で成功率を評価する場合、「悪い」と判定するための閾値(成功率閾値)が設けられる。成功率が成功率閾値より悪い(値が小さい)リソースは、成功率が「悪い」と評価される。成功率が成功率閾値以上のリソースは、成功率が「良い」と評価される。
成功率の閾値は、操作対象の各リソースの成功率の平均値とのかい離率に基づいて設定することもできる。例えばリソース統計情報解析部122cは、操作対象の各リソースの成功率の平均値を計算する。そしてリソース統計情報解析部122cは、例えば操作対象のリソースの成功率から平均値を減算し、減算結果を平均値で除算する。リソース統計情報解析部122cは、除算結果を、成功率のかい離率とする。リソース統計情報解析部122cは、成功率のかい離率の閾値と、各リソースの成功率のかい離率とを比較して、成功率を評価する。例えばリソース統計情報解析部122cは、リソースの成功率のかい離率の絶対値が、成功率のかい離率の閾値より大きく、かつそのリソースの成功率のかい離率が負の値の場合、成功率が「悪い」と評価する。またリソース統計情報解析部122cは、リソースの成功率のかい離率の絶対値が、成功率のかい離率の閾値以下である場合、またはリソースの成功率のかい離率の絶対値が正の値の場合、成功率が「良い」と評価する。
なお、具体的な成功率のかい離率の閾値は、運用形態やマシンスペックなどに応じて、任意に設定できる。
図8の例では、処理時間が短い「リソースB」について成功率が「悪い」と評価され、他のリソースは成功率が良いと評価されている。この場合、リソース統計情報解析部122cは、リソース一覧33に登録されている各リソースのうち、成功率が「悪い」リソースが最上位となるように並べ替える。
このとき、リソース統計情報解析部122cは、各リソースへの処理(例えば準備確認処理)の処理方法を、リソース一覧33に設定する。例えば処理時間は短いが成功率は「悪い」リソースの処理の処理方法は「先行実施」に設定される。成功率が「良い」リソースの送信方法は、「並列処理」に設定される。図8の例では、「リソースB」の処理方法が「先行実施」であり、その他のリソースの処理方法が「並列処理」である。
処理方法「先行実施」とされたリソースは、処理方法「並列処理」のリソースよりも先に処理の要求が送信される。そして、処理方法「先行実施」のリソースの処理が完了するまで、処理方法「並列処理」のリソースへの処理の要求は待たされる。
処理方法「並列処理」とされたリソースは、処理方法「並列処理」の他のリソースと共に、並列に処理される。すなわち「並列処理」のリソースへは、「並列処理」の他のリソースの処理が完了するのを待たずに、処理の要求が送信される。なお「並列処理」の複数のリソースそれぞれへの処理の要求は、リソース一覧33の上位のリソースから順番に送信される。
処理時間が短いリソースの成功率が悪い場合、そのリソースの処理が成功したことを確認後に他のリソースへの処理の要求を送信することで、処理時間が短いリソースでの処理失敗時のロールバックを短時間で行うことができる。ロールバックとは、リソースの状態を、処理の実行前の状態に戻すことである。処理時間が短いリソースでの処理に失敗したとき、他のリソースへは、まだ処理の要求が送信されていない。そのため、他のリソースへの処理要求の送信を抑止でき、通信回数が削減されると共に、処理時間が短縮される。
また、処理時間が長いリソースの成功率が悪い場合もある。この場合の並べ替えの例を図9に示す。
図9は、成功率に基づくリソース一覧の並べ替えの第2の例を示す図である。図9の例では、処理時間が長い「リソースC」について成功率が「悪い」と評価され、他のリソースは成功率が良いと評価されている。この場合、リソース統計情報解析部122cは、リソース一覧33に登録されている各リソースの並べ替えを行わない。
このとき、リソース統計情報解析部122cは、各リソースへの処理(例えば準備確認処理)の処理方法を、リソース一覧33に設定する。例えば成功率に関係なく、すべてのリソースの処理の処理方法が「並列処理」に設定される。
このように処理時間が長いリソースの成功率が悪い場合、そのリソースに処理を先行して実施させると、他のリソースへ処理の要求を送信するのが遅れてしまい、全体として処理の効率の低下が大きくなる。そのため、処理時間が長いリソースの成功率が悪い場合には、すべてのリソースに並列に処理を実行させる方が適切となる。
なお、成功率が「悪い」リソースがない場合には、要求の送信順は、処理時間に応じた順番のままとなる。その場合の処理方法は、すべてのリソースについて「並列処理」となる。
このような処理の順番の判定処理の手順の詳細を、以下に説明する。
図10は、順番判定処理の手順の一例を示す図である。
[ステップS101]リソース統計情報解析部122cは、操作対象の各リソースの処理時間のかい離率を計算する。
[ステップS102]リソース統計情報解析部122cは、操作対象の各リソースについて、かい離率に基づいて処理時間を評価する。例えば、かい離率の絶対値が閾値により高く、かい離率が正の値のリソースは、処理時間が「長い」と判断される。また例えば、かい離率の絶対値が閾値により高く、かい離率が負の値のリソースは、処理時間が「短い」と判断される。さらにかい離率が閾値以下のリソースは、処理時間が「普通」と判断される。
[ステップS103]リソース統計情報解析部122cは、リソース一覧33を、処理時間の評価によってソートする。例えば、処理時間が「長い」リソースが最上位、処理時間が「普通」のリソースをその次、処理時間が「短い」リソースが最下位となるように、リソースがソートされる。
[ステップS104]リソース統計情報解析部122cは、成功率の悪いリソースを抽出する。例えばリソース統計情報解析部122cは、リソース一覧33から、成功率の平均からのかい離率が所定値以上ある、平均より悪い成功率のリソースを抽出する。
[ステップS105]リソース統計情報解析部122cは、成功率の悪いリソースがあったか否かを判断する。成功率の悪いリソースがある場合、処理がステップS106に進められる。成功率の悪いリソースがなければ、処理がステップS109に進められる。
[ステップS106]成功率が悪いリソースが存在する場合、リソース統計情報解析部122cは、成功率が悪いリソースの処理時間の評価が「短い」か否かを判断する。処理時間の評価が「短い」であれば、処理がステップS107に進められる。処理時間の評価が「長い」または「普通」であれば、処理がステップS109に進められる。
[ステップS107]成功率が悪いリソースの処理時間の評価が「短い」である場合、リソース統計情報解析部122cは、抽出したリソースを、リソース一覧33の最上位に移動する。
[ステップS108]リソース統計情報解析部122cは、抽出したリソースの処理方法を「先行処理」に決定し、その処理方法をリソース一覧33に設定する。またリソース統計情報解析部122cは、抽出したリソース以外のリソースの処理方法を「並列処理」に決定し、その処理方法をリソース一覧33に設定する。その後、順番判定処理が終了する。
[ステップS109]成功率が悪いリソースがないか、あるいは成功率の悪いリソースの処理時間の評価が「短い」以外の場合、リソース統計情報解析部122cは、すべてのリソースの処理方法を「並列処理」に決定する。そして、リソース統計情報解析部122cは、決定した処理方法を、リソース一覧33に設定する。その後、順番判定処理が終了する。
このようにして、効率的な処理順が決定される。
図11は、コミット処理の第1の例を示す図である。図11には、処理時間の短いリソースでの処理の成功率が悪くない場合の例が示されている。この場合、処理時間が長い順に、各リソースに、リソース操作処理の要求が送信される。そして各リソースでの処理が、並列に実行される。
図11の例では、エンタープライズ情報システム231の処理時間が最も長く、次にデータベースシステム211の処理時間が長く、メッセージングシステム221の処理時間が最も短い。この場合、トランザクション制御部120は、エンタープライズ情報システム231、データベースシステム211、メッセージングシステム221の順で、リソース操作処理の要求を送信する。図11の例は、2フェーズコミットでのトランザクションである。そこで、まず準備確認フェーズのリソース操作が以下の手順で行われる。
最初に、トランザクション制御部120は、準備確認のリソース操作の要求をエンタープライズ情報システム231に送信する(ステップS41)。これにより、エンタープライズ情報システム231において、準備確認の処理が実行される(ステップS42)。次にトランザクション制御部120は、準備確認のリソース操作の要求をデータベースシステム211に送信する(ステップS43)。これにより、データベースシステム211において、準備確認の処理が実行される(ステップS44)。さらにトランザクション制御部120は、準備確認のリソース操作の要求をメッセージングシステム221に送信する(ステップS45)。これにより、メッセージングシステム221において、準備確認の処理が実行される(ステップS46)。各リソースは、リソース操作の準備が完了すると、準備完了の応答をトランザクション制御部に送信する。
トランザクション制御部120により、すべてのリソースから準備完了を示す応答を受信したことが確認されると、操作反映フェーズのリソース操作が以下の手順で行われる。
最初に、トランザクション制御部120は、操作反映のリソース操作の要求をエンタープライズ情報システム231に送信する(ステップS51)。これにより、エンタープライズ情報システム231において、操作反映の処理が実行される(ステップS52)。次にトランザクション制御部120は、操作反映のリソース操作の要求をデータベースシステム211に送信する(ステップS53)。これにより、データベースシステム211において、操作反映の処理が実行される(ステップS54)。さらにトランザクション制御部120は、操作反映のリソース操作の要求をメッセージングシステム221に送信する(ステップS55)。これにより、メッセージングシステム221において、操作反映の処理が実行される(ステップS56)。各リソースは、リソース操作の反映が完了すると、反映完了の応答をトランザクション制御部に送信する。
図11に示したような順番でリソース操作の要求を送信することで、2フェーズコミットによるトランザクションが効率的に実行される。すなわち、各フェーズの処理時間は、最も処理時間の長いリソースの処理時間と等しくなる。一方、処理時間の短いリソースへ先に処理要求を送信すると、図11の例では、メッセージングシステム221への処理要求の送信からエンタープライズ情報システム231への処理要求の送信までの時間だけ、余分に時間がかかる。
しかも、ネットワーク上では、処理要求の転送が出力順に行われるため、処理要求の送信時刻の差が、ネットワーク上での処理要求の転送順に影響を及ぼす。すなわちネットワークにおいて処理要求を転送する機器(ルータやスイッチ)は、先に送信された処理要求を優先的に転送する。そのためネットワークが混雑していると、トランザクション制御部120からの処理要求の送出時間の差よりも、各リソースでの処理要求の受信時間の差が拡大することがある。図11に示すように、処理時間が短いリソースに対する処理要求のネットワークでの転送の遅延が多少拡大しても、各フェーズにおける処理時間に対して影響を及ぼさずにすむ。その結果、ネットワークの混雑によるトランザクションの長期化が抑止される。
次に、処理時間が短いリソースの処理の成功率が低い場合の例について説明する。
図12は、コミット処理の第2の例を示す図である。図12には、処理時間の短いリソースでの処理の成功率が悪い場合の例が示されている。この場合、処理時間が短いリソースに、リソース操作の要求が先行して送信される。そして、そのリソースの処理の結果に応じたリソース操作の要求が送信される。例えば処理時間が短いリソースの準備確認が正常に完了すれば、他のリソースへの準備確認のリソース操作の要求が送信される。他方、処理時間が短いリソースの準備確認が異常終了すれば、すべてのリソースへのロールバックのリソース操作の要求が送信される。図12には、処理時間が短いリソースの準備確認が異常終了した場合の例が示されている。
図12の例では、エンタープライズ情報システム231の処理時間が最も長く、次にデータベースシステム211の処理時間が長く、メッセージングシステム221の処理時間が最も短い。またメッセージングシステム221の処理の成功率は低い。この場合、トランザクション制御部120は、最初に準備確認のリソース操作の要求を、メッセージングシステム221に送信する(ステップS61)。これにより、メッセージングシステム221において、準備確認の処理が実行される(ステップS62)。準備確認が異常終了すると、メッセージングシステム221は、異常を示す操作結果を、トランザクション制御部120に応答する。
トランザクション制御部120は、準備確認に対する異常の応答を受け取ると、すべてのリソースに対してロールバックのリソース操作の要求を送信する。例えばトランザクション制御部120は、ロールバックのリソース操作の要求を、処理時間が長いリソースから順に送信する。図12の例では、トランザクション制御部120は、まず、エンタープライズ情報システム231に送信する(ステップS71)。これにより、エンタープライズ情報システム231において、ロールバックの処理が実行される(ステップS72)。次に、トランザクション制御部120は、データベースシステム211に対して、ロールバックのリソース操作の要求を送信する(ステップS73)。これにより、データベースシステム211において、ロールバックの処理が実行される(ステップS74)。さらにトランザクション制御部120は、メッセージングシステム221に対して、ロールバックのリソース操作の要求を送信する(ステップS75)。これにより、メッセージングシステム221において、ロールバック処理が実行される(ステップS76)。
このように、成功率が低く、かつ処理時間が短いメッセージングシステム221に対するリソース操作を先行実施することで、操作が異常終了した場合のロールバックを迅速に行うことができる。すなわち、図11に示したように、メッセージングシステム221へのリソース操作の処理要求の送信を最後に行うと、メッセージングシステム221から異常の応答を受信する時期が遅れる。その結果、ロールバックを開始する時期が遅れてしまう。図12に示すように、メッセージングシステム221へのリソース操作を先行実施すれば、早期に異常終了の応答を受信し、ロールバックを開始できる。しかも、メッセージングシステム221の処理時間は短いため、トランザクション全体の処理の長期化は、最小限に抑えることができる。
以上説明したように、第2の実施の形態によれば、処理的に処理できる順番で、処理の要求を送信するようにしたため、トランザクション全体の効率化を図ることができる。しかも第2の実施の形態では、処理時間が短いリソースでの成功率が低い場合、そのリソースへの処理要求を先行して実施し、そのリソースでの処理が正常に完了したことを確認した後に、他のリソースへの処理要求を送信するようにしている。これにより、処理の成功率の低いリソースでの処理が異常終了した場合のロールバックを迅速に行うことができる。
〔その他の実施の形態〕
第2の実施の形態では、トランザクションが行われるごとに、リソース統計情報を更新している。この場合、システムの運用開始後の初期段階では、リソース統計情報算出の元となるトランザクションの数が少なく、統計的な信頼性に乏しくなる。そこで、リソース統計情報の初期設定として、数パターンのデフォルトの統計情報雛型を容易することができる。例えば、以下の手順でリソース統計情報の初期設定をすることができる。
[第1のステップ]システムの管理者は、リソース統計情報の複数の雛形から、使用する雛形を決定する。
例えば、以下の観点でデフォルトのリソース統計情報の雛型を数パターン用意される。
・リソース数(参加リソース数の少ない、多い)
・ネットワーク環境(回線速度、回線品質)
・マシンスペック(高スペック、低スペック)
管理者は、数パターンの雛型より適用する環境に最も近い雛型を選択する。雛形には、例えばリソース名や場所が空欄の状態で、リソースの処理時間や成功率が予め設定されている。また雛形には、所定量のトランザクション回数が設定されている。例えば適用するシステムと同程度の規模のシステムにおいて、所定期間(例えば1日)に処理するトランザクション回数が設定される。雛形の成功回数は、トランザクション回数と成功率から算出した値である。
[第2のステップ]システムの管理者は、適用するシステムのリソースの情報(リソース名や場所)を、決定した雛形に入力する。この際、管理者は、処理時間が遅いと想定される以下のリソースの優先順位が高くなるように、リソース情報を登録する。
・回線速度が遅いネットワークに配置されるリソース
・マシンスペックが低いマシンに配置されるリソース
[第3のステップ]システムの管理者は、処理時間の評価における「長い/短い」の判断の閾値を変更する。例えば、管理者は以下の考え方で閾値を変更する。
・各リソースの処理時間のバラツキが小さい場合は、閾値を小さくする。
・各リソースの処理時間のバラツキが大きい場合は、閾値を大きくする。
このような閾値の変更は、例えば管理者がアプリケーションサーバ100に、「長い/短い」の判断の閾値を入力することで実施される。なおアプリケーションサーバ100には、処理時間の評価における「長い/短い」の判断の閾値の初期値(デフォルト値)を予め設定しておくことができる。閾値として初期値を使用できる場合、管理者は、閾値の変更処理を行わなくてもよい。
[第4のステップ]システムの管理者は、成功率の評価における「良い/悪い」の判断の閾値を変更する。例えば管理者は、以下の考え方で閾値を変更する。
・各リソースの成功率が良い場合は、閾値を小さくする。
・各リソースの成功率が悪い場合は、閾値を大きくする。
このような閾値の変更は、例えば管理者がアプリケーションサーバ100に、「良い/悪い」の判断の閾値を入力することで実施される。なおアプリケーションサーバ100には、成功率の評価における「良い/悪い」の判断の閾値の初期値(デフォルト値)を予め設定しておくことができる。閾値として初期値を使用できる場合、管理者は、閾値の変更処理を行わなくてもよい。
[第5のステップ]システムの管理者は、編集した雛形を、リソース統計情報32の初期値として適用する。例えばシステムの管理者は、編集後の雛形のリソース統計情報記憶部122aへの格納指示を、アプリケーションサーバ100に入力する。するとアプリケーションサーバ100において、編集後の雛形が、リソース統計情報32としてリソース統計情報記憶部122aに格納される。そして、システムの運用が開始される。
このように、雛形を用いてリソース統計情報の初期値を設定できるようにすることで、以下の利点がある。
・運用の当初から、効率的なトランザクションを実施できる。
・処理順番の決定における精度向上までの時間を短縮できる。
また、リソース統計情報を不揮発化することもできる。不揮発化とは、不揮発性の記録媒体に保存することである。
リソース統計情報を不揮発化することで、以下の利点がある。
・予期しないシステムダウンによるリソース統計情報の損失を防止できる。
・不揮発化することでリソース統計情報のマシン間における持ち運びが可能となり、適用環境からクローン環境へ、または試験環境から運用環境へなどの持ち運びでリソース統計情報の流用が可能になる。
リソース統計情報の不揮発化方法としては、例えば、トランザクション制御部120がメモリ102上に展開しているリソース統計情報32を、入出力装置であるHDD103にコピーする。不揮発化を行うタイミングは任意に指定可能である。例えば不揮発化のタイミングとして、以下のようにしてタイミングを指定可能である。
・不揮発化の実施時刻を指定する。
・運用停止時に不揮発化を実施することを指定する。
・通信時における処理時間の「短い/長い」の閾値を超過するリソースの検出時に不揮発化を実施することを指定する。
・処理時間の「短い/長い」の閾値の超過回数が所定値を超えた場合に、不揮発化を実施することを指定する。
・処理結果における成功率の「良い/悪い」の閾値を超過するリソース検出時に不揮発化を実施することを指定する。
・処理結果における成功率の「良い/悪い」の閾値の超過回数が所定値を超えた場合に、不揮発化を実施することを指定する。
以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の2以上の構成(特徴)を組み合わせたものであってもよい。
1〜3 装置
4 ネットワーク
10 情報処理装置
11 記憶手段
11a 統計情報
12 決定手段
13 制御手段

Claims (5)

  1. 複数の装置それぞれで提供されるリソースを更新するトランザクションの実行時に、前記トランザクションに含まれる複数の処理を並列で実行させる、前記複数の装置のうちの少なくとも一部の複数の並列実行装置のうち、処理に要する時間が所定値より長い並列実行装置への処理要求が、他の並列実行装置よりも先に送信されるように、前記複数の並列実行装置への処理要求の送信順を決定する決定手段と、
    該送信順で、前記トランザクションの結果を前記複数の並列実行装置それぞれに確定させる処理要求を、前記複数の並列実行装置それぞれに対して送信し、前記複数の並列実行装置に並列に処理を実行させる制御手段と、
    を有する情報処理装置。
  2. 前記決定手段は、前記複数の装置から、処理の成功率が所定の成功率判定値未満であり、かつ処理時間が所定の処理時間判定値未満の装置を特定し、前記複数の装置のうちの、該特定した装置以外の装置を、並列に処理を実行させる前記複数の並列実行装置とすることを特徴とする請求項記載の情報処理装置。
  3. 前記決定手段は、前記複数の装置における処理の平均の成功率からの、前記複数の装置それぞれの成功率のかい離率を計算し、成功率のかい離率が閾値未満の装置を特定することを特徴とする請求項記載の情報処理装置。
  4. 前記制御手段は、前記特定した装置に対して先行して処理要求を送信し、該装置から処理が正常に完了したことを示す応答を受信した後、並列に処理を実行させる前記複数の並列実行装置それぞれに対して処理要求を送信することを特徴とする請求項または記載の情報処理装置。
  5. 前記制御手段は、トランザクションの2フェーズコミットにおけるリソース操作の処理要求を、決定された送信順で送信することを特徴とする請求項乃至のいずれかに記載の情報処理装置。
JP2013074295A 2013-03-29 2013-03-29 情報処理装置、処理要求プログラム、および処理要求方法 Expired - Fee Related JP6171494B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2013074295A JP6171494B2 (ja) 2013-03-29 2013-03-29 情報処理装置、処理要求プログラム、および処理要求方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2013074295A JP6171494B2 (ja) 2013-03-29 2013-03-29 情報処理装置、処理要求プログラム、および処理要求方法

Publications (2)

Publication Number Publication Date
JP2014199534A JP2014199534A (ja) 2014-10-23
JP6171494B2 true JP6171494B2 (ja) 2017-08-02

Family

ID=52356402

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013074295A Expired - Fee Related JP6171494B2 (ja) 2013-03-29 2013-03-29 情報処理装置、処理要求プログラム、および処理要求方法

Country Status (1)

Country Link
JP (1) JP6171494B2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106303125B (zh) * 2015-06-03 2019-12-03 腾讯科技(深圳)有限公司 自动充值系统、方法及装置

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008159019A (ja) * 2006-12-01 2008-07-10 Hitachi Ltd プログラムの実行処理装置

Also Published As

Publication number Publication date
JP2014199534A (ja) 2014-10-23

Similar Documents

Publication Publication Date Title
US20220335034A1 (en) Multi-master architectures for distributed databases
CN109582335B (zh) 一种无中断存储集群节点在线升级方法、装置及设备
CN111338773A (zh) 一种分布式定时任务调度方法、调度系统及服务器集群
US11314545B2 (en) Predicting transaction outcome based on artifacts in a transaction processing environment
WO2019056771A1 (zh) 分布式存储系统升级管理的方法、装置及分布式存储系统
WO2022134797A1 (zh) 一种数据分片存储方法、装置、计算机设备和存储介质
CN111277639A (zh) 一种保持数据一致性的方法和装置
CN111400041A (zh) 服务器配置文件的管理方法、装置及计算机可读存储介质
WO2020238860A1 (zh) 分布式文件批处理方法、装置、与可读存储介质
CN110012054B (zh) 一种基于联盟链网络的业务处理方法及系统
CN113010786B (zh) 信息推送的方法、装置、设备以及存储介质
WO2021135742A1 (zh) 对账清算方法及装置
CN114625566A (zh) 数据容灾方法、装置、电子设备及存储介质
JP6171494B2 (ja) 情報処理装置、処理要求プログラム、および処理要求方法
US20190149460A1 (en) Optimized Message Flooding Across Nodes of a Distributed Platform
CN105391755A (zh) 一种分布式系统中数据处理方法、装置及系统
US11881996B2 (en) Input and output for target device communication
JP2010152435A (ja) 情報処理装置及び情報処理方法及びプログラム
JP6127754B2 (ja) プログラム、排他制御要求振り分け方法およびシステム
CN113253924A (zh) 数据处理方法、装置、电子设备及计算机可读存储介质
CN110839064A (zh) 一种分布式系统执行脚本的方法及装置
CN111488333B (zh) 数据处理方法及装置、存储介质和电子设备
CN113032477A (zh) 基于gtid的长距离数据同步方法、装置及计算设备
CN112187842A (zh) 局域网数据处理系统与局域网数据处理方法
CN112783613A (zh) 一种单元调度的方法和装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20151204

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160831

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160920

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20161118

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20170131

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170428

A911 Transfer of reconsideration by examiner before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20170511

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170606

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170619

R150 Certificate of patent or registration of utility model

Ref document number: 6171494

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees