(57)【要約】【課題】接続情報の不整合を抑止すること。【解決手段】監視部１ｃは、サービス提供部１ｂの稼働状況を監視する。送信部１ｄは、監視部１ｃがサービス提供部１ｂの起動完了を検知すると所定の制御情報を送信する。サービス提供部１ｂは、所定のリソースを介してサービス提供部１ｂに処理要求を送信する。接続情報記憶部２ａは、リソースを定義した接続情報を記憶する。制御部２ｃは、情報処理装置１から制御情報を受信すると、受信した制御情報に基づき接続情報記憶部２ａに記憶された接続情報に含まれるリソースを無効とする。【選択図】図１
2011159014.tif 000002
【特許請求の範囲】
【請求項１】
処理要求に応じた処理を実行する第１のサービス提供部と、
前記第１のサービス提供部の稼働状況を監視する監視部と、
前記監視部が前記第１のサービス提供部の起動完了を検知すると所定の制御情報を送信する送信部と、
を備える第１の情報処理装置と、
所定のリソースを介して前記第１のサービス提供部に前記処理要求を送信する第２のサービス提供部と、
前記リソースを定義した接続情報を記憶する接続情報記憶部と、
前記第１の情報処理装置から制御情報を受信すると、受信した制御情報に基づき前記接続情報記憶部に記憶された前記接続情報に含まれる前記リソースを無効とする制御部と、
を備える第２の情報処理装置と、
を有することを特徴とする情報処理システム。
【請求項２】
前記監視部は、前記第１のサービス提供部の起動完了を検知すると第１の版数記憶部に記憶された所定の第１の版数を更新し、
前記送信部は、前記監視部が更新した前記第１の版数を制御情報に含めて前記第２の情報処理装置に送信し、
前記接続情報記憶部は、前記リソースに対応付けて当該リソースが割り当てられた時点を示す所定の第２の版数を記憶し、
前記制御部は、前記第１の情報処理装置から受信した制御情報に含まれる前記第１の版数が前記第２の版数と異なる場合に前記リソースを無効とする、
ことを特徴とする請求項１記載の情報処理システム。
【請求項３】
前記送信部は、前記第１のサービス提供部が前記処理要求に対する応答を前記第２のサービス提供部に送信する際に、前記第１の版数記憶部に記憶された前記第１の版数を含む制御情報を送信する、
ことを特徴とする請求項２記載の情報処理システム。
【請求項４】
前記第１のサービス提供部が起動状態の場合には停止状態となり、前記第１のサービス提供部が停止状態の場合には起動状態となって前記第２のサービス提供部から受信した前記処理要求に応じて前記第１のサービス提供部の処理を代替する冗長サービス提供部と、
前記冗長サービス提供部の稼働状況を監視する冗長監視部と、
前記冗長監視部が前記冗長サービス提供部の停止を検知すると所定の制御情報を送信する冗長送信部と、
を備える第３の情報処理装置を更に有し、
前記第１のサービス提供部は、前記冗長サービス提供部が停止すると起動を開始する、
ことを特徴とする請求項２または３の何れか一項に記載の情報処理システム。
【請求項５】
前記冗長監視部は、前記冗長サービス提供部の停止を検知すると第３の版数記憶部に記憶された所定の第３の版数を更新し、
前記冗長送信部は、前記冗長監視部が更新した前記第３の版数を制御情報に含めて前記第２の情報処理装置に送信し、
前記制御部は、前記第３の情報処理装置から受信した制御情報に含まれる前記第３の版数が前記第２の版数と異なる場合に前記リソースを無効とする、
ことを特徴とする請求項４記載の情報処理システム。
【請求項６】
前記第１の情報処理装置は、
前記第２のサービス提供部からの割当要求に応じて前記リソースの割り当てを行い、前記リソースの割り当てを管理するためのリソース管理情報を生成するリソース制御部と、
前記リソース管理情報を記憶するリソース情報記憶部と、
を更に有し、
前記第２の情報処理装置は、
前記第２のサービス提供部の稼働状態を監視するサービス監視部と、
前記サービス監視部が前記第２のサービス提供部の停止および起動を検知すると所定の通知情報を送信する通知情報送信部と、
を更に有し、
前記リソース制御部は、前記第２の情報処理装置から受信した前記通知情報に基づき前記リソース情報記憶部に記憶された前記リソース管理情報に含まれる前記リソースのうち、前記第２のサービス提供部に割り当てたリソースを解放する、
ことを特徴とする請求項１乃至５の何れか一項に記載の情報処理システム。
【請求項７】
前記サービス監視部は、前記第２のサービス提供部の停止および起動を検知すると、第４の版数記憶部に記憶された所定の第４の版数を更新し、
前記通知情報送信部は、前記サービス監視部が更新した前記第４の版数を前記通知情報に含めて前記第１の情報処理装置に送信し、
前記リソース情報記憶部は、前記第２のサービス提供部により前記割当要求が送信された時点を示す所定の第５の版数を前記リソースに対応付けて記憶し、
前記リソース制御部は、前記第２の情報処理装置から受信した前記通知情報に含まれる前記第４の版数が前記第５の版数と異なる場合に前記第２のサービス提供部に割り当てたリソースを解放する、
ことを特徴とする請求項６記載の情報処理システム。
【請求項８】
前記通知情報送信部は、前記第２のサービス提供部が前記処理要求を送信する際に、前記第４の版数記憶部に記憶された前記第４の版数を含む前記通知情報を送信することを特徴とする請求項７記載の情報処理システム。
【請求項９】
第１のサービス提供部の稼働状況を監視する監視部と、
前記監視部が前記第１のサービス提供部の起動完了を検知すると、第２のサービス提供部を備える相手装置に、前記第２のサービス提供部が前記第１のサービス提供部に処理要求を送信するために用いるリソースを定義した接続情報を記憶する接続情報記憶部に記憶された前記接続情報に含まれる前記リソースの無効化を促す制御情報を送信する送信部と、
を有することを特徴とする情報処理装置。
【請求項１０】
第１のサービス提供部が相手装置の備える第２のサービス提供部に処理要求を送信するために用いられるリソースを定義した接続情報を記憶する接続情報記憶部と、
前記第２のサービス提供部の起動完了が前記相手装置側で検知された際に、前記相手装置から送信される所定の制御情報を受信すると、受信した制御情報に基づき前記接続情報記憶部に記憶された前記接続情報に含まれる前記リソースを無効とする制御部と、
を有することを特徴とする情報処理装置。
【請求項１１】
コンピュータを、
第１のサービス提供手段の稼働状況を監視する監視手段、
前記監視手段が前記第１のサービス提供手段の起動完了を検知すると、第２のサービス提供手段を備える情報処理装置に、前記第２のサービス提供手段が前記第１のサービス提供手段に処理要求を送信するために用いるリソースを定義した接続情報を記憶する接続情報記憶手段に記憶された前記接続情報に含まれる前記リソースの無効化を促す制御情報を送信する送信手段、
として機能させることを特徴とする通信制御プログラム。
【請求項１２】
コンピュータを、
第１のサービス提供手段により情報処理装置が備える第２のサービス提供手段に処理要求を送信するために用いられるリソースを定義した接続情報を記憶する接続情報記憶手段、
前記第２のサービス提供手段の起動完了が前記情報処理装置側で検知された際に、前記情報処理装置から送信される所定の制御情報を受信すると、受信した制御情報に基づき前記接続情報記憶手段に記憶された前記接続情報に含まれる前記リソースを無効とする制御手段、
として機能させることを特徴とする通信制御プログラム。
【請求項１３】
情報処理システムの通信制御方法であって、
第１の情報処理装置が、処理要求に応じた処理を実行する第１のサービス提供部の稼働情報を監視し、前記第１のサービス提供部の起動完了を検知すると所定の制御情報を送信し、
第２の情報処理装置が、前記第１の情報処理装置から制御情報を受信すると、第２のサービス提供部が前記第１のサービス提供部に前記処理要求を送信するために用いる所定のリソースを定義した接続情報を記憶する接続情報記憶部に記憶された前記接続情報に含まれる前記リソースを無効とする、
ことを特徴とする通信制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバ間通信を制御するための接続情報を管理する情報処理システム、情報処理装置、通信制御プログラムおよび通信制御方法に関する。
【背景技術】
【０００２】
従来、ネットワークで接続された複数の情報処理装置間でデータ通信を行う情報処理システムが利用されている。この情報処理システムとして、例えば業務アプリケーションプログラムを実行するアプリケーション（ＡＰ：Application）サーバと各種データを格納するデータベース（ＤＢ：Database）サーバとを接続した業務処理システムがある。
【０００３】
この業務処理システムでは、ＡＰサーバとＤＢサーバとの間の通信をセッション（Session）と呼ばれる接続情報単位で管理する。例えば、ＡＰサーバはＤＢサーバとの通信を行うためにＤＢサーバからセッションの払い出しを受ける。ＡＰサーバは払い出されたセッションをＤＢサーバに対応付けて接続情報として管理する。一方、ＤＢサーバも払い出したセッションをＡＰサーバに対応付けて接続情報として管理する。ＡＰサーバは、確立したセッションを介してＤＢサーバに処理を要求する。ＤＢサーバは、そのセッションを介してＡＰサーバに応答する。
【０００４】
しかし、通信を行う都度セッションの確立を行うとすると、高頻度で通信が発生した場合にセッション要求・払い出しが多発する。このため、各サーバで通信が輻輳したり、処理負荷が増大したりする可能性がある。
【０００５】
これに対し、例えばＡＰサーバは、利用すべき複数のセッションをＤＢサーバとの間で予め合意・確立して保持しておくことが考えられる。この場合、ＡＰサーバは割り当てられたセッションを再利用してＤＢサーバと通信する。このような技術は、セッションプール（Session Pool）と呼ばれる。セッションプールを用いることで、セッション確立を通信発生の都度行う必要がなくなる。そのため、上述のような輻輳等を抑止できる。
【０００６】
ところで、上述の業務処理システムではセッションを管理する機能の障害によってサーバ間のデータ通信に支障がでる場合がある。業務処理システムでは、その運用にあたり、このような障害への対応を適切に行えることが望ましい。
【０００７】
そこで、セッションの確立から解放までを単位として、その間の通信情報を適切に取得する方法がある（例えば、特許文献１参照）。また、要求元装置から要求された処理につきセッションを介してデータベースへアクセスできない場合に、要求元装置に効率的にエラーを送信する方法がある（例えば、特許文献２参照）。
【０００８】
更に、業務処理システムを負荷分散構成とすることが考えられる。例えば、複数のＡＰサーバと複数のＤＢサーバとを設ける。このようにすると、例えばＡＰ層（ＡＰサーバの集合）およびＤＢ層（ＤＢサーバの集合）で負荷の均一化を図ることができる。また、例えばＡＰサーバやＤＢサーバの何れかでサービスの提供機能に障害が発生したとしても業務処理を継続できる。すなわち、業務処理システム全体の応答性や可用性を向上できる。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特許２９２８１５７号公報
【特許文献２】特開２００９−１５７６６２号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
上述のように業務処理システムを負荷分散構成とすると、障害の発生したサーバは処理の振り分け先から除外される。そして、サービスの提供機能が復旧すると、そのサーバへの処理の振り分けが再開される。
【００１１】
しかし、処理の要求元サーバ（例えば、ＡＰサーバ）では、復旧したサーバ（例えば、ＤＢサーバ）との間で障害前に確立していたセッションの管理情報が残存する場合がある。一方、復旧したサーバ（例えば、ＤＢサーバ）ではサービス提供機能のメンテナンス（例えば、再起動）が行われることで、障害前に保持されたセッションはクリアされる。
【００１２】
この場合、要求元サーバでセッションの管理情報が残存しても、復旧したサーバ側には対応するセッションが存在しないことになる。このため、要求元サーバがそのセッションを用いて通信しようとしても、両サーバで管理するセッションの不整合から通信が行えずにエラーになるという問題があった。また、このエラーにより業務処理が遅延する、適正に処理を行えない等の問題が生じていた。
【００１３】
本発明はこのような点に鑑みてなされたものであり、接続情報の不整合を抑止する情報処理システム、情報処理装置、通信制御プログラムおよび通信制御方法を提供することを目的とする。
【課題を解決するための手段】
【００１４】
本発明では上記課題を解決するために、情報処理システムが提供される。この情報処理システムは、第１の情報処理装置と第２の情報処理装置とを備える。第１の情報処理装置は、第１のサービス提供部、監視部および送信部を備える。第１のサービス提供部は、処理要求に応じた処理を実行する。監視部は、第１のサービス提供部の稼働状況を監視する。送信部は、監視部が第１のサービス提供部の起動完了を検知すると所定の制御情報を送信する。第２の情報処理装置は、第２のサービス提供部、接続情報記憶部および制御部を有する。第２のサービス提供部は、所定のリソースを介して第１のサービス提供部に処理要求を送信する。接続情報記憶部は、リソースを定義した接続情報を記憶する。制御部は、第１の情報処理装置から制御情報を受信すると、受信した制御情報に基づき接続情報記憶部に記憶された接続情報に含まれる前記リソースを無効とする。
【００１５】
また、上記課題を解決するために情報処理装置が提供される。この情報処理装置は、監視部および送信部を有する。監視部は、第１のサービス提供部の稼働状況を監視する。送信部は、監視部が第１のサービス提供部の起動完了を検知すると、第２のサービス提供部を備える相手装置に、第２のサービス提供部が第１のサービス提供部に処理要求を送信するために用いるリソースを定義した接続情報を記憶する接続情報記憶部に記憶された接続情報に含まれるリソースの無効化を促す制御情報を送信する。
【００１６】
また、上記課題を解決するために情報処理装置が提供される。この情報処理装置は、接続情報記憶部および制御部を有する。接続情報記憶部は、第１のサービス提供部により相手装置が備える第２のサービス提供部に処理要求を送信するために用いられるリソースを定義した接続情報を記憶する。制御部は、第２のサービス提供部の起動完了が相手装置側で検知された際に、相手装置から送信される所定の制御情報を受信すると、受信した制御情報に基づき接続情報記憶部に記憶された接続情報に含まれるリソースを無効とする。
【００１７】
また、上記課題を解決するために通信制御プログラムが提供される。この通信制御プログラムを実行するコンピュータは、監視手段および送信手段として機能する。監視手段は、第１のサービス提供手段の稼働状況を監視する。送信手段は、監視手段が第１のサービス提供手段の起動完了を検知すると、第２のサービス提供手段を備える情報処理装置に、第２のサービス提供手段が第１のサービス提供手段に処理要求を送信するために用いるリソースを定義した接続情報を記憶する接続情報記憶手段に記憶された接続情報に含まれるリソースの無効化を促す制御情報を送信する。
【００１８】
また、上記課題を解決するために通信制御プログラムが提供される。この通信制御プログラムを実行するコンピュータは、接続情報記憶手段および制御手段として機能する。接続情報記憶手段は、第１のサービス提供手段により情報処理装置が備える第２のサービス提供手段に処理要求を送信するために用いられるリソースを定義した接続情報を記憶する。制御手段は、第２のサービス提供手段の起動完了が情報処理装置側で検知された際に、情報処理装置から送信される所定の制御情報を受信すると、受信した制御情報に基づき接続情報記憶手段に記憶された接続情報に含まれるリソースを無効とする。
【００１９】
また、上記課題を解決するために情報処理システムの通信制御方法が提供される。この通信制御方法では、第１の情報処理装置が、処理要求に応じた処理を実行する第１のサービス提供部の稼働情報を監視し、第１のサービス提供部の起動完了を検知すると所定の制御情報を送信する。そして、第２の情報処理装置が、第１の情報処理装置から制御情報を受信すると、第２のサービス提供部が第１のサービス提供部に処理要求を送信するために用いる所定のリソースを定義した接続情報を記憶する接続情報記憶部に記憶された接続情報に含まれるリソースを無効とする。
【発明の効果】
【００２０】
上記情報処理システム、情報処理装置、通信制御プログラムおよび通信制御方法によれば、接続情報の不整合を抑止できる。
【図面の簡単な説明】
【００２１】
【図１】第１の実施の形態に係る情報処理システムを示す図である。
【図２】第２の実施の形態に係る業務処理システムを示す図である。
【図３】第２の実施の形態のＤＢサーバのハードウェア構成を示す図である。
【図４】第２の実施の形態のＤＢサーバの機能構成を示す図である。
【図５】第２の実施の形態のＡＰサーバの機能構成を示す図である。
【図６】ＤＢサーバが有するクラスタ版数テーブルのデータ構造例を示す図である。
【図７】ＡＰサーバが有する版数管理テーブルのデータ構造例を示す図である。
【図８】ＡＰサーバが有するセッション管理テーブルのデータ構造例を示す図である。
【図９】第２の実施の形態のＤＢサーバ切替処理を示すシーケンス図である。
【図１０】第２の実施の形態のＤＢサービス停止時版数通知処理を示すフローチャートである。
【図１１】第２の実施の形態のＤＢサービス起動時版数通知処理を示すフローチャートである。
【図１２】第２の実施の形態のセッション無効化処理を示すフローチャートである。
【図１３】第２の実施の形態の業務処理を示すシーケンス図である。
【図１４】第２の実施の形態のＤＢリクエスト送信処理を示すフローチャートである。
【図１５】第２の実施の形態のセッション割当処理を示すフローチャートである。
【図１６】第２の実施の形態のＤＢレスポンス送信処理を示すフローチャートである。
【図１７】第２の実施の形態のＤＢレスポンス受信処理を示すフローチャートである。
【図１８】第２の実施の形態のセッション整理処理を示すフローチャートである。
【図１９】第２の実施の形態のセッション無効化処理を示す第１のシーケンス図である。
【図２０】第２の実施の形態のセッション無効化処理を示す第２のシーケンス図である。
【図２１】第２の実施の形態のセッション無効化処理を示す第３のシーケンス図である。
【図２２】第３の実施の形態のＤＢサーバの機能構成を示す図である。
【図２３】第３の実施の形態のＡＰサーバの機能構成を示す図である。
【図２４】ＤＢサーバが有する版数管理テーブルのデータ構造例を示す図である。
【図２５】ＤＢサーバが有するセッション管理テーブルのデータ構造例を示す図である。
【図２６】ＡＰサーバが有するサーバ版数テーブルのデータ構造例を示す図である。
【図２７】第３の実施の形態のＡＰサーバの縮退開始／縮退解除処理を示すシーケンス図である。
【図２８】第３の実施の形態のＡＰサービス停止時版数通知処理を示すフローチャートである。
【図２９】第３の実施の形態のＡＰサービス起動時版数通知処理を示すフローチャートである。
【図３０】第３の実施の形態のセッション解放処理を示すフローチャートである。
【図３１】第３の実施の形態の業務処理を示すシーケンス図である。
【図３２】第３の実施の形態のＤＢリクエスト送信処理を示すフローチャートである。
【図３３】第３の実施の形態のセッション割当処理を示すフローチャートである。
【図３４】第３の実施の形態のセッション開設処理を示すフローチャートである。
【図３５】第３の実施の形態のＤＢレスポンス送信処理を示すフローチャートである。
【図３６】第３の実施の形態のセッション解放処理を示す第１のシーケンス図である。
【図３７】第３の実施の形態のセッション解放処理を示す第２のシーケンス図である。
【発明を実施するための形態】
【００２２】
以下、本実施の形態を図面を参照して詳細に説明する。
［第１の実施の形態］
図１は、第１の実施の形態に係る情報処理システムを示す図である。この情報処理システムは、情報処理装置１と情報処理装置２とがネットワークを介して接続される。
【００２３】
情報処理装置１は、接続情報記憶部１ａ、サービス提供部１ｂ、監視部１ｃおよび送信部１ｄを有する。
接続情報記憶部１ａは、サービス提供部１ｂがサービス提供部２ｂとの通信に用いるリソースを定義した接続情報を記憶する。サービス提供部２ｂは、そのリソースを介してサービス提供部１ｂに処理要求を送信することができる。接続情報に定義されたリソースとは、例えばセッションである。
【００２４】
通信に用いるリソースは、情報処理装置１と情報処理装置２との間で、予め合意がなされる。例えば、情報処理装置１は、情報処理装置１にアクセスするためのリソースを情報処理装置２に予め割り当てる。情報処理装置１は、割り当てたリソースを接続情報として接続情報記憶部１ａに格納して管理する。情報処理装置２では、割り当てられたリソースを接続情報として接続情報記憶部２ａに格納して管理する。リソースの割り当ては、例えば情報処理装置１が情報処理装置２から割当要求を受信した際に実行される。
【００２５】
サービス提供部１ｂは、情報処理装置１上で実行されるアプリケーションプログラムである。サービス提供部１ｂは、接続情報記憶部１ａに記憶された接続情報に定義されたリソースを介してサービス提供部２ｂとデータ通信する。
【００２６】
サービス提供部１ｂは、サービス提供部２ｂから受信した処理要求に従った処理を実行する。サービス提供部１ｂは、その実行結果をサービス提供部２ｂに応答する。サービス提供部１ｂは、例えばＤＢアプリケーションのプロセスである。
【００２７】
監視部１ｃは、サービス提供部１ｂの稼働状況を監視する。監視部１ｃは、サービス提供部１ｂの起動完了を検知すると、その旨を送信部１ｄに通知する。
送信部１ｄは、監視部１ｃがサービス提供部１ｂの起動完了を検知すると、情報処理装置２に、接続情報記憶部２ａに記憶された接続情報の無効化を促す制御情報を送信する。
【００２８】
情報処理装置２は、接続情報記憶部２ａ、サービス提供部２ｂおよび制御部２ｃを有する。
接続情報記憶部２ａは、サービス提供部２ｂがサービス提供部１ｂとの通信に用いるリソースを定義した接続情報を記憶する。
【００２９】
サービス提供部２ｂは、情報処理装置２上で実行されるアプリケーションプログラムである。サービス提供部２ｂは、接続情報記憶部２ａに記憶された接続情報に定義されたリソースを介してサービス提供部１ｂとデータ通信する。サービス提供部２ｂは、サービス提供部１ｂに処理を要求し、サービス提供部１ｂからその応答を受け付ける。サービス提供部２ｂは、サービス提供部１ｂからの応答に基づいて、例えば業務処理を実行する。サービス提供部２ｂは、業務処理の実行結果に基づいて、例えばサービス提供部１ｂに処理要求を更に送信する。あるいは、サービス提供部２ｂは、例えば不図示のクライアント装置に業務処理の実行結果を更に送信する。サービス提供部２ｂは、例えば業務アプリケーションのプロセスである。
【００３０】
制御部２ｃは、送信部１ｄが送信した制御情報を受信すると、接続情報記憶部２ａに記憶された接続情報を無効にする。
このような情報処理装置１によれば、監視部１ｃにより、サービス提供部１ｂの稼働状況が監視される。送信部１ｄにより、監視部１ｃがサービス提供部１ｂの起動完了を検知すると、接続情報記憶部２ａに記憶された接続情報の無効化を促す制御情報が情報処理装置２に送信される。
【００３１】
これにより、サービス提供部１ｂが起動した際に、接続情報記憶部２ａに残存する接続情報（すなわち、接続情報に含まれるリソース）を無効とすることができる。したがって、サービス提供部２ｂがその接続情報を用いてサービス提供部１ｂに通信を試みることがなくなる。すなわち、接続情報の不整合を抑止できる。その結果、不整合によるエラーの発生を抑止できる。
【００３２】
なお、残存する接続情報を無効とした後に、情報処理装置２は、その接続情報に含まれるリソースを破棄することもできる。破棄するタイミングを、業務アプリケーションの処理の進捗に応じて変更することもできる。例えば、実行中の業務アプリケーションのトランザクションによって無効としたリソースがロックされている場合も考えられる。その場合、例えば該当のトランザクションが完了した後にリソースを破棄することもできる。このようにすると、リソースの破棄を確実に行える。
【００３３】
また、上述の説明ではサービス提供部１ｂとしてＤＢアプリケーションのプロセスを例示した。そして、サービス提供部２ｂとして業務アプリケーションのプロセスを例示した。これに対し、サービス提供部１ｂを業務アプリケーションのプロセスとし、サービス提供部２ｂをＤＢアプリケーションのプロセスとしてもよい。その場合、情報処理装置１は、情報処理装置２からリソースの割り当てを受ける。すなわち、制御部２ｃは、情報処理装置１でサービス提供部１ｂが起動すると送信部１ｄから受信した制御情報に基づいて、情報処理装置２が情報処理装置１に割り当てた接続情報を無効にする。情報処理装置２は、その後、無効とした接続情報に含まれるリソースを解放することができる。これにより、情報処理装置２は利用されなくなったリソースの再利用が可能となる。
【００３４】
以下の実施の形態では、複数のＡＰサーバと複数のＤＢサーバとを有するより具体的な情報処理システムを例に採り、詳細に説明する。
［第２の実施の形態］
以下、第２の実施の形態を図面を参照して詳細に説明する。
【００３５】
図２は、第２の実施の形態に係る業務処理システムを示す図である。この業務処理システムは、ＤＢクラスタ１０，２０，３０、負荷分散装置４０、端末装置６１，６２，６３，・・・およびＡＰサーバ４００，５００，６００を有する。ＤＢクラスタ１０，２０，３０、端末装置６１，６２，６３，・・・およびＡＰサーバ４００，５００，６００は、負荷分散装置４０およびネットワーク５０，６０を介して接続される。ネットワーク５０，６０は、例えばイントラネット、あるいはこの業務処理システムのために設けられたその他の専用通信網である。以下では、ネットワーク５０，６０がＴＣＰ／ＩＰ（Transmission Control Protocol / Internet Protocol）により通信するネットワークである場合を例示する。
【００３６】
ＤＢクラスタ１０，２０，３０は、ＤＢサーバをクラスタ化してデータアクセスの高信頼化を図るものである。ＤＢクラスタ１０は、ストレージ装置１１およびＤＢサーバ１００，１００ａを有する。ＤＢクラスタ２０は、ストレージ装置２１およびＤＢサーバ２００，２００ａを有する。ＤＢクラスタ３０は、ストレージ装置３１およびＤＢサーバ３００，３００ａを有する。
【００３７】
ストレージ装置１１は、ＤＢサーバ１００，１００ａの共用ストレージである。ストレージ装置１１は、業務処理システムに用いる各種業務データを記憶する。ストレージ装置１１は、所定のインタフェース（例えば、ファイバーチャネル）によりＤＢサーバ１００，１００ａと接続される。
【００３８】
ＤＢサーバ１００，１００ａは、ストレージ装置１１に記憶された業務データを管理する。ＤＢサーバ１００，１００ａは、二重化によるフォールトトレラント（Fault tolerant）を実現する。具体的には、クラスタリングによる冗長構成となっている。そのため、ＤＢサーバ１００，１００ａはハートビート（Heart Beat）用のネットワークで接続される。例えば、ＤＢサーバ１００が現用系、ＤＢサーバ１００ａが待機系となっている場合、ＤＢサーバ１００ａはＤＢサーバ１００からハートビートパケットを受信できなくなることで、ＤＢサーバ１００のサービスダウンを検知できる。そして、ＤＢサーバ１００ａはＤＢサーバ１００に代替してＤＢサービスの提供を開始する。
【００３９】
ＤＢクラスタ１０には、ＤＢサーバ１００，１００ａを束ねる単一の仮想的なＩＰアドレス（ＤＢ仮想アドレスという）が割り当てられる。ＤＢサーバ１００，１００ａは、個別の実ＩＰアドレスに対応付けてＤＢ仮想アドレスを共有する。ＤＢサーバ１００，１００ａは、ＤＢ仮想アドレスに対する外部装置からの処理要求が現用系サーバに到達するよう自サーバにおけるＤＢ仮想アドレスの死活を制御する。すなわち、現用系サーバではＤＢ仮想アドレスがアクティブとなる。待機系サーバではＤＢ仮想アドレスが非アクティブとなる。
【００４０】
ＤＢクラスタ２０，３０についてもＤＢクラスタ１０と同様の構成により実現することができる。
負荷分散装置４０は、端末装置６１，６２，６３から受け付けた処理要求をＡＰサーバ４００，５００，６００に振り分ける。
【００４１】
負荷分散装置４０の負荷分散方法には、例えばラウンドロビン、最小コネクションおよび最小応答時間などがある。ラウンドロビンは、各サーバに順番に処理を割り当てる方法である。最小コネクションは、各サーバのうち、ＴＣＰコネクションやＵＤＰ（User Datagram Protocol）フローの数が最も少ないサーバに処理を割り当てる方法である。最小応答時間は、各サーバの応答時間を測定し、応答時間が短いサーバに処理を割り当てる方法である。
【００４２】
負荷分散装置４０はＡＰサーバ４００，５００，６００のＩＰアドレスを単一の仮想アドレスに対応付けて管理する。端末装置６１，６２，６３，・・・は、負荷分散装置４０上の仮想アドレスに処理要求を送信する。すると、負荷分散装置４０は、ＡＰサーバ４００，５００，６００の何れかに処理を振り分ける。なお、負荷分散装置４０は、ＡＰサーバ４００，５００，６００の死活監視により利用不可と判断したサーバを処理の振り分け先から除外する。
【００４３】
端末装置６１，６２，６３，・・・は、業務処理システムを利用するユーザが扱うコンピュータである。端末装置６１，６２，６３，・・・は、業務処理システムに対する業務処理要求の入力が行えるようＧＵＩ（Graphical User Interface）をユーザに提供する。ユーザは、ＧＵＩに従って端末装置６１，６２，６３，・・・に対する操作入力を行うことで業務処理システムに所望の処理を実行させることができる。
【００４４】
ＡＰサーバ４００，５００，６００は、端末装置６１，６２，６３，・・・から受け付けた業務処理要求に対して、業務処理を実行する。ＡＰサーバ４００，５００，６００は、端末装置６１，６２，６３，・・・に対して、ユーザ用のＧＵＩを生成するための情報を送信するＷｅｂサーバとしても機能する。
【００４５】
また、ＡＰサーバ４００，５００，６００は業務処理の必要に応じて、ＤＢクラスタ１０，２０，３０の何れかに処理要求を送信する。具体的には、ＡＰサーバ４００，５００，６００は、ラウンドロビンによりＤＢクラスタ１０，２０，３０に処理要求を順に振り分ける。なお、ＡＰサーバ４００，５００，６００は、ＤＢクラスタ１０，２０，３０が現在運用中であるか否かを管理する。ＡＰサーバ４００，５００，６００は、運用中でないＤＢクラスタを処理要求の送信先から除外する。
【００４６】
図３は、第２の実施の形態のＤＢサーバのハードウェア構成を示す図である。ＤＢサーバ１００は、ＣＰＵ（Central Processing Unit）１０１、ＲＯＭ（Read Only Memory）１０２、ＲＡＭ（Random Access Memory）１０３、ディスクアレイインタフェース１０４、グラフィック処理装置１０５、入力インタフェース１０６、記録媒体読取装置１０７および通信インタフェース１０８を有する。
【００４７】
ＣＰＵ１０１は、ＤＢサーバ１００全体を制御する。
ＲＯＭ１０２は、ＤＢサーバ１００上のＢＩＯＳ（Basic Input / Output System）のプログラムなどを記憶する。
【００４８】
ＲＡＭ１０３は、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションソフトウェア（以下、アプリケーションという）のプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ１０３は、ＣＰＵ１０１による処理に必要な各種データを記憶する。
【００４９】
ディスクアレイインタフェース１０４は、ストレージ装置１１と接続される。ディスクアレイインタフェース１０４は、ストレージ装置１１に内蔵されたＲＡＩＤ（Redundant Arrays of Independent Disks）コントローラと通信し、ストレージ装置１１に対するデータの入出力を行う。ストレージ装置１１内のＲＡＩＤコントローラは、例えばＲＡＩＤ０〜６の何れかの機能を有し、複数のＨＤＤ（Hard Disk Drive）をまとめて冗長化された記憶装置として管理する。ストレージ装置１１は、ＡＰサーバ４００，５００，６００が扱うデータを記憶する。
【００５０】
また、ストレージ装置１１は、ＯＳのプログラム、アプリケーションのプログラム及びデータを記憶する。ＯＳのプログラム、アプリケーションのプログラム及びデータは、例えばストレージ装置１１とは別個に設けられた他の記憶装置に格納されてもよい。
【００５１】
なお、ストレージ装置１１はＨＤＤに代えて（または、ＨＤＤと併せて）、ＳＳＤ（Solid State Drive）など他の種類の記憶装置を用いてもよい。
グラフィック処理装置１０５は、モニタ１２と接続される。グラフィック処理装置１０５は、ＣＰＵ１０１からの命令に従って画像をモニタ１２の画面に表示させる。
【００５２】
入力インタフェース１０６は、キーボード１３とマウス１４と接続される。入力インタフェース１０６は、キーボード１３やマウス１４から送られてくる信号をＣＰＵ１０１に送信する。
【００５３】
記録媒体読取装置１０７は、記録媒体１５に記憶されたデータを読み取る読取装置である。例えば、ＤＢサーバ１００が有すべき機能は、その機能の処理内容を記述したプログラムをコンピュータに実行させることで実現できる。そのようなプログラムは、コンピュータ読み取り可能な記録媒体１５に記録して配布することができる。また、ネットワーク５０に接続されたプログラム配信サーバ装置（図示せず）に記録媒体１５からそのプログラムを格納してもよい。この場合、ＤＢサーバ１００は、ネットワーク５０を介してプログラム配信サーバ装置からプログラムをダウンロードすることができる。
【００５４】
記録媒体１５としては、例えば、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリを使用できる。磁気記録装置には、ＨＤＤ、フレキシブルディスク（ＦＤ：Flexible Disk）、磁気テープなどがある。光ディスクには、ＣＤ（Compact Disc）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−Ｒ／ＲＷ／ＲＡＭなどがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。半導体メモリには、ＵＳＢ（Universal Serial Bus）メモリなどのフラッシュメモリがある。
【００５５】
通信インタフェース１０８は、ネットワーク５０と接続される。通信インタフェース１０８は、ネットワーク５０を介して他の情報処理装置とデータ通信する。
なお、ＤＢサーバ１００ａ，２００，２００ａ，３００，３００ａ、ＡＰサーバ４００，５００，６００および端末装置６１，６２，６３，・・・もＤＢサーバ１００と同様のハードウェア構成により実現できる。ただし、ＡＰサーバ４００，５００，６００および端末装置６１，６２，６３，・・・は、ストレージ装置１１やディスクアレイインタフェース１０４に代えてＨＤＤやＳＳＤ等の記憶装置を内蔵することができる。
【００５６】
図４は、第２の実施の形態のＤＢサーバの機能構成を示す図である。ＤＢサーバ１００は、版数記憶部１１０、ＤＢ処理部１２０、クラスタ制御部１３０、サービス監視部１４０、版数送信部１５０およびＡＰ通信部１６０を有する。これらの機能は、ＣＰＵ１０１が所定のプログラムを実行することで実現される。なお、これらの機能の全部あるいは少なくとも一部を専用のハードウェアを用いて実現してもよい。
【００５７】
版数記憶部１１０は、ＤＢクラスタ１０の版数（以下、クラスタ版数という）を記憶する。クラスタ版数の詳細は後述する。
ＤＢ処理部１２０は、ＤＢに対する処理要求を実行する。例えば、ＤＢ処理部１２０は、ストレージ装置１１に記憶されたデータの読み出しや更新を行う。ＤＢ処理部１２０は、処理要求に対する応答をＡＰ通信部１６０に出力する。
【００５８】
クラスタ制御部１３０は、ＤＢ処理部１２０が稼働状態である間、ＤＢサーバ１００ａにハートビートパケットを送信する。これにより、クラスタ制御部１３０は自サーバが現用系として動作していることをＤＢサーバ１００ａに通知する。また、クラスタ制御部１３０は、版数記憶部１１０、ＤＢ処理部１２０、サービス監視部１４０、版数送信部１５０およびＡＰ通信部１６０の各機能の起動・停止を制御する。すなわち、クラスタ制御部１３０は、ＤＢサーバ１００ａが待機系として動作する場合、自サーバを現用系として動作させるためにこれらの各機能を起動させる。
【００５９】
サービス監視部１４０は、ＤＢ処理部１２０の起動・停止を監視する。サービス監視部１４０は、ＤＢ処理部１２０が起動または停止した場合に、版数記憶部１１０に記憶されたクラスタ版数を更新する。
【００６０】
版数送信部１５０は、サービス監視部１４０により版数記憶部１１０に記憶されたクラスタ版数が更新されると、そのクラスタ版数をＡＰサーバ４００，５００，６００に送信する。
【００６１】
ＡＰ通信部１６０は、ＡＰサーバ４００，５００，６００と通信する。ＡＰ通信部１６０は、ＡＰサーバ４００，５００，６００から処理要求を受信し、ＤＢ処理部１２０に出力する。また、ＡＰ通信部１６０は、ＤＢ処理部１２０から取得した応答を処理要求の送信元であるＡＰサーバ４００，５００，６００に送信する。
【００６２】
ＤＢサーバ１００ａは、版数記憶部１１０ａ、ＤＢ処理部１２０ａ、クラスタ制御部１３０ａ、サービス監視部１４０ａ、版数送信部１５０ａおよびＡＰ通信部１６０ａを有する。これらの機能は、ＤＢサーバ１００ａが備えるＣＰＵが所定のプログラムを実行することで実現される。なお、これらの機能の全部あるいは少なくとも一部を専用のハードウェアを用いて実現してもよい。
【００６３】
ここで、版数記憶部１１０ａは版数記憶部１１０に対応する。ＤＢ処理部１２０ａはＤＢ処理部１２０に対応する。クラスタ制御部１３０ａはクラスタ制御部１３０に対応する。サービス監視部１４０ａはサービス監視部１４０に対応する。版数送信部１５０ａは版数送信部１５０に対応する。ＡＰ通信部１６０ａはＡＰ通信部１６０に対応する。
【００６４】
版数記憶部１１０ａ、ＤＢ処理部１２０ａ、サービス監視部１４０ａ、版数送信部１５０ａおよびＡＰ通信部１６０ａの各機能の起動・停止はクラスタ制御部１３０ａによって制御される。
【００６５】
なお、クラスタ制御部１３０ａは、ＤＢサーバ１００が現用系として動作している場合には、これらの機能の停止状態を維持する。一方、ＤＢサーバ１００が利用不可となった場合には、自サーバを現用系として動作させるためにこれらの各機能を起動させる。
【００６６】
すなわち、ＤＢサーバ１００ａの各機能は、ＤＢサーバ１００の各機能の代替を可能とするための冗長機能である。
また、ＤＢクラスタ２０，３０についてもＤＢクラスタ１０と同様の機能構成により実現できる。
【００６７】
図５は、第２の実施の形態のＡＰサーバの機能構成を示す図である。ＡＰサーバ４００は、セッション情報記憶部４１０、ＡＰ処理部４２０、クライアント通信部４３０、セッション制御部４４０、版数受信部４５０およびＤＢ通信部４６０を有する。これらの機能は、ＡＰサーバ４００が備えるＣＰＵが所定のプログラムを実行することで実現される。なお、これらの機能の全部あるいは少なくとも一部を専用のハードウェアを用いて実現してもよい。
【００６８】
セッション情報記憶部４１０は、ＤＢクラスタ１０，２０，３０のクラスタ版数を記憶する。また、セッション情報記憶部４１０は、ＤＢクラスタ１０，２０，３０から割り当てられたセッションを定義したセッション情報を記憶する。
【００６９】
ＡＰ処理部４２０は、端末装置６１，６２，６３，・・・から取得した業務処理要求を実行する。ＡＰ処理部４２０は、業務処理の内容に応じて、ＤＢクラスタ１０，２０，３０に対する処理要求（例えば、ＳＱＬで記述されたクエリ）を生成する。ＡＰ処理部４２０は、生成した処理要求をＤＢ通信部４６０に出力する。
【００７０】
また、ＡＰ処理部４２０は、ＤＢ通信部４６０から処理要求に対するＤＢクラスタ１０，２０，３０からの応答を受け付ける。ＡＰ処理部４２０は、その応答に基づいて、処理要求を再生成してＤＢ通信部４６０に出力する。あるいは、ＡＰ処理部４２０は端末装置６１，６２，６３，・・・からの業務処理要求に対する処理を完了すると、業務応答を生成してクライアント通信部４３０に出力する。
【００７１】
クライアント通信部４３０は、端末装置６１，６２，６３，・・・と通信する。クライアント通信部４３０は、端末装置６１，６２，６３，・・・から受信した業務処理要求をＡＰ処理部４２０に出力する。また、クライアント通信部４３０は、ＡＰ処理部４２０から取得した業務応答を端末装置６１，６２，６３，・・・に送信する。
【００７２】
セッション制御部４４０は、セッション情報記憶部４１０に記憶されたＤＢクラスタ１０，２０，３０のクラスタ版数およびセッション情報を管理する。セッション制御部４４０は、予めＤＢクラスタ１０，２０，３０との間でデータ通信に利用するセッションの割り当てを受け、割り当てられたセッションをセッション情報としてセッション情報記憶部４１０に格納する。
【００７３】
セッション制御部４４０は、ＤＢクラスタ１０，２０，３０のクラスタ版数に基づいて、セッションの無効化を制御する。セッション制御部４４０は、セッション情報記憶部４１０に記憶されたセッション情報を参照して、処理要求を送信すべきＤＢクラスタとそのＤＢクラスタとの通信に利用可能なセッションとをＤＢ通信部４６０に出力する。
【００７４】
版数受信部４５０は、ＤＢクラスタ１０，２０，３０から各クラスタのクラスタ版数を受信する。版数受信部４５０は、受信したクラスタ版数をセッション制御部４４０に出力する。
【００７５】
ＤＢ通信部４６０は、セッション制御部４４０により指定されたＤＢクラスタに対し、指定されたセッションを用いてＤＢクラスタ１０，２０，３０と通信する。ＤＢ通信部４６０は、ＡＰ処理部４２０から処理要求を取得すると、取得した処理要求をＤＢクラスタ１０，２０，３０に送信する。ＤＢ通信部４６０は、ＤＢクラスタ１０，２０，３０から応答を受け付けると、ＡＰ処理部４２０に出力する。
【００７６】
なお、ＡＰサーバ５００，６００に関してもＡＰサーバ４００と同様の機能構成により実現できる。
図６は、ＤＢサーバが有するクラスタ版数テーブルのデータ構造例を示す図である。クラスタ版数テーブル１１１は、サービス監視部１４０により更新され、版数記憶部１１０に格納される。クラスタ版数テーブル１１１には、ＤＢクラスタ１０のクラスタ版数が設定される。
【００７７】
クラスタ版数テーブル１１１には、例えば“１２５７０５１２００”という情報が設定される。これは、１９７０年１月１日０時０分０秒からの秒数である。サービス監視部１４０はクラスタ版数テーブル１１１を更新する際に、例えばＯＳからこのような時間情報をクラスタ版数として取得できる。
【００７８】
なお、クラスタ版数はＤＢサービス起動中から起動直後の時点では所定の初期値（例えば“−１”）が設定されるものとする。そして、起動完了後の所定のタイミングで、サービス監視部１４０により、現在の時間情報がクラスタ版数として設定される。
【００７９】
図７は、ＡＰサーバが有する版数管理テーブルのデータ構造例を示す図である。版数管理テーブル４１１は、セッション制御部４４０により更新され、セッション情報記憶部４１０に格納される。版数管理テーブル４１１には、クラスタ名を示す項目、クラスタ版数を示す項目および運用状態を示す項目が設けられている。各項目の横方向に並べられた情報同士が互いに関連付けられて、１つのＤＢクラスタに関する情報を示す。
【００８０】
クラスタ名を示す項目には、クラスタ名を示す情報が設定される。クラスタ版数を示す項目には、クラスタ版数を示す情報が設定される。運用状態を示す項目には、運用中であるか否かを示す情報が設定される。
【００８１】
版数管理テーブル４１１には、例えばクラスタ名が“ＤＢ０００１”、クラスタ版数が“１２５７０４３２１０”、運用状態が“運用中”という情報が設定される。これは、クラスタ名“ＤＢ０００１”で示されるＤＢクラスタ１０のクラスタ版数が“１２５７０４３２１０”であることを示している。また、ＤＢクラスタ１０は現在“運用中”であるため、処理要求の送信対象とすることができる旨を示している。
【００８２】
ここで、以下ではＤＢクラスタ２０のクラスタ名を“ＤＢ０００２”、ＤＢクラスタ３０のクラスタ名を“ＤＢ０００３”とする。
図８は、ＡＰサーバが有するセッション管理テーブルのデータ構造例を示す図である。セッション管理テーブル４１２，４１３，４１４は、セッション制御部４４０により更新され、セッション情報記憶部４１０に格納される。セッション管理テーブル４１２はＤＢクラスタ１０に対応する。セッション管理テーブル４１３はＤＢクラスタ２０に対応する。セッション管理テーブル４１４はＤＢクラスタ３０に対応する。以下では、セッション管理テーブル４１２に関してのみ説明するが、セッション管理テーブル４１３，４１４に関しても同様の構成である。
【００８３】
セッション管理テーブル４１２には、エントリＩＤを示す項目、要求元識別情報を示す項目、セッション取得時版数を示す項目、セッション番号を示す項目及び無効フラグを示す項目が設けられている。各項目の横方向に並べられた情報同士が互いに関連付けられて、１つのセッションに関する情報を示す。
【００８４】
エントリＩＤを示す項目には、セッション管理テーブル４１２に含まれる１レコードを識別するためのエントリＩＤが設定される。要求元識別情報を示す項目には、業務処理要求の送信元である端末装置の識別情報が設定される。セッション取得時版数を示す項目には、該当のレコードに対応するセッションが確立された際のクラスタ版数が設定される。セッション番号を示す項目には、ＤＢクラスタ１０から割り当てられたセッションを識別するためのセッション番号が設定される。無効フラグを示す項目には、該当のセッションが無効であるか否かを示す情報が設定される。
【００８５】
セッション管理テーブル４１２には、例えばエントリＩＤが“１”、要求元識別情報が“ＣＬ０００５”、セッション取得時版数が“１２５７０４５３４０”、セッション番号が“４”、無効フラグが“−”（設定なし）という情報が設定される。これは、“ＣＬ０００５”で識別される端末装置から受け付けた業務処理要求につき、ＤＢクラスタ１０上のセッション番号“４”で識別されるセッションを利用してＤＢクラスタ１０と通信していることを示している。また、このセッションを取得した際のＤＢクラスタ１０のクラスタ版数が“１２５７０４５３４０”であることを示している。また、無効フラグが“−”であり、そのセッションは有効であることを示している。
【００８６】
また、セッション管理テーブル４１２には、例えばエントリＩＤが“１１”、要求元情報が“ＣＬ０００３”、セッション取得時版数が“１２５７０３８２２９”、セッション番号が“１１”、無効フラグが“無効”という情報が設定される。ここで、当レコードには無効フラグに“無効”が設定されている。これは、当レコードに対応するセッションが利用不可であることを示している。すなわち、ＤＢクラスタ１０には、ＡＰサーバ４００と通信するためのセッションとして、セッション番号“１１”のセッションが既に存在していないことを示す。
【００８７】
ここで、セッション管理テーブル４１２にはＤＢクラスタ１０がＡＰサーバ４００に対してプール可能なセッション数の上限（例えば、５０）が予め設定される。以下では、この上限値をプール上限値という。セッション制御部４４０は、所定のタイミングでＤＢクラスタ１０から払い出されたセッション数のプール上限値の超過の有無を監視する。そして、超過している場合にプールされたセッションの整理（例えば、不要なセッションの破棄要求をＤＢクラスタ１０に送信する）を行う。このようにすると、ＤＢクラスタ１０がＡＰサーバ４００に対して払い出すセッション数が他のＡＰサーバに比べて過大となることを防止できる。
【００８８】
次に、以上のような構成を備える業務処理システムの処理手順を説明する。ここで、以下ではＤＢクラスタ１０およびＡＰサーバ４００に注目して処理手順を説明する。ただし、ＤＢクラスタ１０とＡＰサーバ５００，６００との間の処理も同様である。また、ＤＢクラスタ２０，３０とＡＰサーバ４００，５００，６００との間の処理も同様である。
【００８９】
図９は、第２の実施の形態のＤＢサーバ切替処理を示すシーケンス図である。以下、図９に示す処理をステップ番号に沿って説明する。なお、ステップＳ１の直前では、ＤＢクラスタ１０において、ＤＢサーバ１００が現用系、ＤＢサーバ１００ａが待機系であるものとする。
【００９０】
［ステップＳ１］ＤＢサーバ１００は、ＤＢサービス（ＤＢ処理部１２０）の停止指示を受け付ける。この停止指示を受け付ける場合としては、例えばシステム管理者がメンテナンスのためにサービス停止を指示する操作入力をＤＢサーバ１００に対して行った場合等が考えられる。
【００９１】
［ステップＳ２］ＤＢサーバ１００は、ＤＢ処理部１２０の停止を開始する。
［ステップＳ３］ＤＢサーバ１００は、ＤＢ処理部１２０の停止が開始されると、版数記憶部１１０に記憶されたクラスタ版数を更新する。ＤＢサーバ１００は、更新したクラスタ版数およびクラスタ停止開始通知をＡＰサーバ４００，５００，６００に送信する。
【００９２】
［ステップＳ４］ＡＰサーバ４００は、ＤＢサーバ１００からクラスタ版数およびクラスタ停止開始通知を受信する。ＡＰサーバ４００は、受信したクラスタ版数に基づいて、ＡＰサーバ４００がＤＢクラスタ１０から割り当てられていたセッションの無効化処理を実行する。
【００９３】
［ステップＳ５］ＡＰサーバ４００は、クラスタ停止開始通知を受信したことにより、セッション情報記憶部４１０に記憶された版数管理テーブル４１１のうち、ＤＢクラスタ１０（クラスタ名“ＤＢ０００１”）の運用状態を“非運用中”に設定する。
【００９４】
［ステップＳ６］ＤＢサーバ１００は、ＤＢ処理部１２０の停止が完了する。
［ステップＳ７］ＤＢサーバ１００ａは、ＤＢサーバ１００からハートビートパケットを受信しなくなったことを検知する。すると、ＤＢサーバ１００ａは、ＤＢサービス（ＤＢ処理部１２０ａ）の起動を開始する。
【００９５】
［ステップＳ８］ＤＢサーバ１００ａは、ＤＢ処理部１２０ａの起動を完了する。
［ステップＳ９］ＤＢサーバ１００ａは、ＤＢ処理部１２０ａの起動が完了すると、版数記憶部１１０ａに記憶されたクラスタ版数を更新する。ＤＢサーバ１００ａは、更新したクラスタ版数およびクラスタ起動完了通知をＡＰサーバ４００，５００，６００に送信する。
【００９６】
［ステップＳ１０］ＡＰサーバ４００は、ＤＢサーバ１００ａからクラスタ版数を受信する。ＡＰサーバ４００は、受信したクラスタ版数に基づいて、ＡＰサーバ４００がＤＢクラスタ１０から割り当てられていたセッションの無効化処理を実行する。
【００９７】
［ステップＳ１１］ＡＰサーバ４００は、クラスタ起動完了通知を受信したことにより、セッション情報記憶部４１０に記憶された版数管理テーブル４１１のうち、ＤＢクラスタ１０（クラスタ名“ＤＢ０００１”）の運用状態を“運用中”に設定する。
【００９８】
このようにして、ＤＢサーバ１００はＤＢ処理部１２０停止時にクラスタ版数をＡＰサーバ４００に送信する。また、ＤＢサーバ１００ａはＤＢ処理部１２０ａ開始時にクラスタ版数をＡＰサーバ４００に送信する。
【００９９】
ＡＰサーバ４００は、ＤＢクラスタ１０（すなわち、ＤＢサーバ１００，１００ａの何れか）からクラスタ版数を受信すると、自装置で管理するＤＢクラスタ１０のクラスタ版数とを比較し、比較結果に応じてＤＢクラスタ１０との間で確立済みのセッションを無効とする。
【０１００】
次に、図９のステップＳ３に示したＤＢクラスタ１０のＤＢサービス停止時版数通知処理を詳細に説明する。
図１０は、第２の実施の形態のＤＢサービス停止時版数通知処理を示すフローチャートである。以下、図１０に示す処理をステップ番号に沿って説明する。
【０１０１】
［ステップＳ２１］クラスタ制御部１３０は、ＤＢ処理部１２０の停止処理を開始させる。サービス監視部１４０は、ＤＢ処理部１２０の停止開始を検知する。
［ステップＳ２２］サービス監視部１４０は、ＯＳから現在のタイムスタンプをクラスタ版数として取得する。
【０１０２】
［ステップＳ２３］サービス監視部１４０は、版数記憶部１１０に記憶されたクラスタ版数テーブル１１１のクラスタ版数を、新たに取得したクラスタ版数に更新する。
［ステップＳ２４］版数送信部１５０は、クラスタ版数テーブル１１１を参照してクラスタ版数を取得し、ＡＰサーバ４００，５００，６００に送信する。また、版数送信部１５０は、クラスタ版数と共に、ＤＢクラスタ１０のクラスタ停止開始通知をＡＰサーバ４００，５００，６００に送信する。
【０１０３】
このようにして、ＤＢサーバ１００は、ＤＢ処理部１２０を停止する際にクラスタ版数を更新する。そして、ＤＢサーバ１００は、更新後のクラスタ版数をＡＰサーバ４００，５００，６００に送信する。
【０１０４】
次に、図９のステップＳ９に示したＤＢクラスタ１０のＤＢサービス起動時版数通知処理を詳細に説明する。
図１１は、第２の実施の形態のＤＢサービス起動時版数通知処理を示すフローチャートである。以下、図１１に示す処理をステップ番号に沿って説明する。
【０１０５】
［ステップＳ３１］サービス監視部１４０ａは、ＤＢ処理部１２０ａの起動完了を検知する。
［ステップＳ３２］サービス監視部１４０ａは、ＯＳから現在のタイムスタンプをクラスタ版数として取得する。
【０１０６】
［ステップＳ３３］サービス監視部１４０ａは、版数記憶部１１０ａに記憶されたクラスタ版数テーブルのクラスタ版数を、新たに取得したクラスタ版数に更新する。
［ステップＳ３４］版数送信部１５０ａは、版数記憶部１１０ａに記憶されたクラスタ版数テーブルを参照してクラスタ版数を取得し、ＡＰサーバ４００，５００，６００に送信する。また、版数送信部１５０ａは、クラスタ版数と共に、ＤＢクラスタ１０のクラスタ起動完了通知をＡＰサーバ４００，５００，６００に送信する。
【０１０７】
このようにして、ＤＢサーバ１００ａは、ＤＢサービスを開始する際にクラスタ版数を更新する。そして、ＤＢサーバ１００ａは、更新後のクラスタ版数をＡＰサーバ４００，５００，６００に送信する。
【０１０８】
次に、図９のステップＳ４，１０に示したＡＰサーバ４００のセッション無効化処理を詳細に説明する。
図１２は、第２の実施の形態のセッション無効化処理を示すフローチャートである。以下、図１２に示す処理をステップ番号に沿って説明する。
【０１０９】
［ステップＳ４１］版数受信部４５０は、ＤＢクラスタ１０からクラスタ版数を受信する。版数受信部４５０は、受信したクラスタ版数をセッション制御部４４０に出力する。
［ステップＳ４２］セッション制御部４４０は、セッション情報記憶部４１０に記憶されたセッション管理テーブル４１２を参照して、ＤＢクラスタ１０に対応するセッションを定義したレコードを取得する。
【０１１０】
［ステップＳ４３］セッション制御部４４０は、取得したレコードのうち、ステップＳ４１で受信したクラスタ版数とセッション取得時版数とが異なるレコードが存在するか否かを判定する。存在する場合、処理をステップＳ４４に進める。存在しない場合、処理をステップＳ４５に進める。
【０１１１】
［ステップＳ４４］セッション制御部４４０は、セッション取得時版数が新たに受信したクラスタ版数と異なるレコードの無効フラグに“無効”を設定する。
［ステップＳ４５］セッション制御部４４０は、セッション情報記憶部４１０に記憶された版数管理テーブル４１１のＤＢクラスタ１０のクラスタ版数として、ステップＳ４１で受信したクラスタ版数を設定する。
【０１１２】
このようにして、セッション制御部４４０は、ＤＢクラスタ１０から受信したクラスタ版数とセッション取得時版数とが異なる場合、該当のセッションを無効とする。
次に、業務処理システムで実行される業務処理の手順を説明する。
【０１１３】
図１３は、第２の実施の形態の業務処理を示すシーケンス図である。以下、図１３に示す処理をステップ番号に沿って説明する。なお、ステップＳ５１の直前では、ＤＢクラスタ１０において、ＤＢサーバ１００が現用系、ＤＢサーバ１００ａが待機系であるものとする。
【０１１４】
［ステップＳ５１］ＡＰサーバ４００は、端末装置６１から業務処理要求（以下、ＡＰリクエストという）を受信する。
［ステップＳ５２］ＡＰサーバ４００は、取得したＡＰリクエストに応じた業務処理を実行する。ＡＰサーバ４００は、業務処理に応じてＤＢクラスタに依頼すべき処理が発生した場合、処理要求（以下、ＤＢリクエストという）を生成する。ＡＰサーバ４００は、生成したＤＢリクエストを送信すべきＤＢクラスタを選択する。例えば、ＡＰサーバ４００はラウンドロビンによって、ＤＢリクエストを送信すべきＤＢクラスタを順番に選択する。ここでは、ＡＰサーバ４００はＤＢクラスタ１０を選択するものとする。そして、ＤＢクラスタ１０にＤＢリクエストを送信する。
【０１１５】
［ステップＳ５３］ＤＢサーバ１００は、ＡＰサーバ４００からＤＢリクエストを受信する。ＤＢサーバ１００は、受信したＤＢリクエストに基づいてＤＢ処理を実行する。ＤＢサーバ１００は、ＤＢ処理の結果に基づいてＤＢレスポンスを生成し、クラスタ版数と共にＡＰサーバ４００に送信する。ここで、ＤＢサーバ１００はＡＰサーバ４００の指定したセッションが無効である場合、ＤＢレスポンスとしてセッション無効通知をクラスタ版数と共に応答する。
【０１１６】
［ステップＳ５４］ＡＰサーバ４００は、ＤＢレスポンスを受信する。ＡＰサーバ４００は、ＤＢレスポンスが正常応答であるか否かを判定する。正常応答でない場合、処理をステップＳ５５に進める。正常応答である場合、処理をステップＳ５６に進める。
【０１１７】
［ステップＳ５５］ＡＰサーバ４００は、セッション無効化処理を実行する。セッション無効化処理は、図１２で説明した処理と同様である。そして、処理をステップＳ５２に進める。
【０１１８】
［ステップＳ５６］ＡＰサーバ４００は、ＤＢレスポンス受信処理を実行する。
［ステップＳ５７］ＡＰサーバ４００は、必要に応じて、ＤＢレスポンスに応じた業務処理を更に実行し、端末装置６１に対するＡＰレスポンスを生成する。そして、ＡＰサーバ４００は生成したＡＰレスポンスを端末装置６１に送信する。
【０１１９】
［ステップＳ５８］ＡＰサーバ４００は、端末装置６１との一連の通信が完了したことを検知する。
［ステップＳ５９］ＡＰサーバ４００は、端末装置６１から要求された業務処理を実行するために管理していた（ＡＰサーバ４００とＤＢクラスタ１０との間の）セッションを整理するための処理を実行する。
【０１２０】
このようにして、ＡＰサーバ４００とＤＢクラスタ１０との間で業務処理に伴う通信が行われる。
次に、図１３のステップＳ５２に示したＡＰサーバ４００のＤＢリクエスト送信処理を説明する。
【０１２１】
図１４は、第２の実施の形態のＤＢリクエスト送信処理を示すフローチャートである。以下、図１４に示す処理をステップ番号に沿って説明する。
［ステップＳ６１］ＡＰ処理部４２０は、ＡＰリクエストに応じた業務処理の実行に伴って、ＤＢクラスタに依頼すべき処理内容を記述したＤＢリクエストを生成する。ＡＰ処理部４２０は、生成したＤＢリクエストをＤＢ通信部４６０に出力する。
【０１２２】
［ステップＳ６２］セッション制御部４４０は、セッション情報記憶部４１０に記憶されたセッション管理テーブル４１２を参照する。
［ステップＳ６３］セッション制御部４４０は、運用状態が“運用中”のＤＢクラスタが存在するか否かを判定する。“運用中”のＤＢクラスタが存在する場合、処理をステップＳ６４に進める。“運用中”のＤＢクラスタが存在しない場合、処理を完了させる。なお、“運用中”のＤＢクラスタが存在しない場合、その後、ＡＰ処理部４２０は、クライアント通信部４３０を介して端末装置６１にエラーを応答し、業務処理を完了させる。
【０１２３】
［ステップＳ６４］セッション制御部４４０は、“運用中”のＤＢクラスタを選択する。セッション制御部４４０は、版数管理テーブル４１１に設定された“運用中”のＤＢクラスタをラウンドロビンによって選択する。例えば、前回の当ステップにおけるクラスタ選択処理においてＤＢクラスタ３０（クラスタ名“ＤＢ０００３”）を選択している場合、今回はＤＢクラスタ１０（クラスタ名“ＤＢ０００１”）を選択する。また、例えば、前回ＤＢクラスタ１０を選択している場合、今回はＤＢクラスタ２０（クラスタ名“ＤＢ０００２”）を選択する。
【０１２４】
［ステップＳ６５］セッション制御部４４０は、選択したＤＢクラスタにつきセッション割当処理を実行する。すなわち、ＤＢ通信部４６０が該当のＤＢクラスタにＤＢリクエストを送信するためのセッションを割り当てる。このとき、例えば該当のＤＢクラスタから予め取得したセッションに空きがなければ、該当のＤＢクラスタにセッションの開設を要求する。そして、ＤＢクラスタから新規セッションの払い出しを受けられれば、そのセッションをＤＢリクエスト送信に割り当てることができる。また、セッションの払い出しを受けられなければ、セッションを割り当てることはできない。
【０１２５】
［ステップＳ６６］セッション制御部４４０は、ＤＢリクエストを送信するためのセッションを割り当てることができたか否かを判定する。割り当てることができた場合、処理をステップＳ６７に進める。割り当てることができなかった場合、処理をステップＳ６３に進める。
【０１２６】
［ステップＳ６７］ＤＢ通信部４６０は、セッション制御部４４０により割り当てられたセッション番号（指定セッションの番号）をＤＢリクエストに含める。そして、ＤＢ通信部４６０はセッション制御部４４０が選択したＤＢクラスタに対し、ＤＢリクエストを送信する。
【０１２７】
このようにして、ＡＰサーバ４００はＤＢリクエストを送信する際に、送信すべきＤＢクラスタを選択し、そのＤＢクラスタとの通信に用いるセッションを割り当てる。
次に、図１４のステップＳ６５に示したＡＰサーバ４００のセッション割当処理を詳細に説明する。
【０１２８】
図１５は、第２の実施の形態のセッション割当処理を示すフローチャートである。以下、図１５に示す処理をステップ番号に沿って説明する。なお、図１４のステップＳ６４でＤＢクラスタ１０が選択されているものとする。
【０１２９】
［ステップＳ７１］セッション制御部４４０は、セッション情報記憶部４１０に記憶されたセッション管理テーブル４１２を参照する。
［ステップＳ７２］セッション制御部４４０は、セッション管理テーブル４１２にエントリされたセッションのうち、何れの端末装置にも割り当てられていない未割当セッションが存在するか否かを判定する。未割当セッションが存在する場合、処理をステップＳ７３に進める。未割当セッションが存在しない場合、処理をステップＳ７６に進める。
【０１３０】
［ステップＳ７３］セッション制御部４４０は、未割当セッションのうち、有効である（すなわち、無効でない）ものが存在するか否かを判定する。存在する場合、処理をステップＳ７８に進める。存在しない場合、処理をステップＳ７４に進める。
【０１３１】
［ステップＳ７４］セッション制御部４４０は、ＤＢクラスタ１０に対してセッション管理テーブル４１２に設定された無効なセッションの破棄を指示する無効セッション破棄要求を生成し、ＤＢ通信部４６０に出力する。ＤＢ通信部４６０は、無効セッション破棄要求をＤＢクラスタ１０に送信する。
【０１３２】
［ステップＳ７５］ＤＢ通信部４６０は、ＤＢクラスタ１０からステップＳ７４で指示したセッションを破棄した旨を示す無効セッション破棄応答を受信する。ＤＢ通信部４６０は、破棄応答をセッション制御部４４０に出力する。
【０１３３】
［ステップＳ７６］セッション制御部４４０は、新たなセッションの開設をＤＢクラスタ１０に要求するためのセッション開設要求を生成し、ＤＢ通信部４６０に出力する。ＤＢ通信部４６０は、生成したセッション開設要求をＤＢクラスタ１０に送信する。
【０１３４】
［ステップＳ７７］ＤＢ通信部４６０は、ＤＢクラスタ１０から新たに割り当てられたセッションを示す新規セッション情報とＤＢクラスタ１０のクラスタ版数とを受信する。ＤＢ通信部４６０は、受信した新規セッション情報とクラスタ版数とをセッション制御部４４０に出力する。セッション制御部４４０は、セッション管理テーブル４１２に新規セッション情報（例えば、セッション番号）を設定する。また、セッション制御部４４０は、新規セッションと共に受信したクラスタ版数を新規セッションに対応するセッション取得時版数として設定する。セッション管理テーブル４１２に設定された新規セッションは未割当セッションとなる。また、新規セッションは有効なセッションとなる。
【０１３５】
［ステップＳ７８］セッション制御部４４０は、セッション管理テーブル４１２を参照して、ＤＢリクエストの生成元となったＡＰリクエストの送信元端末装置の識別情報（要求元識別情報）を有効かつ未割当のセッションに設定する。このとき、例えばセッション管理テーブル４１２に含まれる有効かつ未割当のセッションのうち、エントリＩＤが最も小さいものを優先して選択し、要求元識別情報の設定を行う。これにより、当ＤＢリクエストにつきセッションが割り当てられたことになる。
【０１３６】
このように、ＡＰサーバ４００は有効な未割当セッションが存在すれば、そのセッションを新たな業務処理用のデータ通信に割り当てる。
また、ＡＰサーバ４００は無効な未割当セッションが存在すれば、そのセッションの破棄をＤＢクラスタ１０に指示した後、ＤＢクラスタ１０に新規セッションの払い出しを要求する。そして、ＡＰサーバ４００はＤＢクラスタ１０から新たに取得したセッションを新たな業務処理用のデータ通信に割り当てる。
【０１３７】
また、ＡＰサーバ４００は未割当セッションが存在しない場合、ＤＢクラスタ１０に新規セッションの払い出しを要求する。そして、ＡＰサーバ４００はＤＢクラスタ１０から新たに取得したセッションを新たな業務処理用のデータ通信に割り当てる。
【０１３８】
なお、ＡＰサーバ４００は要求元識別情報で指定される端末装置から受け付ける一連の処理に対して今回割り当てたセッションを継続して用いる。
更に、ステップＳ７７において、ＤＢクラスタ１０から新規セッション情報を取得できない場合も考えられる。その要因として、例えばＤＢクラスタ１０上でのメモリ等の資源不足でセッションの払い出しが行えない、通信経路で障害が発生した等が考えられる。この場合、セッション制御部４４０は、ＤＢリクエストを送信するためのセッションの割り当てを行わずにセッション割当処理を完了する。そして、図１４のステップＳ６３〜６６の処理により、他のＤＢクラスタに処理の割り当てを再度試みる。
【０１３９】
次に、図１３のステップＳ５３に示したＤＢサーバ１００のＤＢレスポンス送信処理を詳細に説明する。
図１６は、第２の実施の形態のＤＢレスポンス送信処理を示すフローチャートである。以下、図１６に示す処理をステップ番号に沿って説明する。
【０１４０】
［ステップＳ８１］ＡＰ通信部１６０は、ＡＰサーバ４００からＤＢリクエストを受信する。ＡＰ通信部１６０は、受信したＤＢリクエストをＤＢ処理部１２０に出力する。
［ステップＳ８２］ＤＢ処理部１２０は、ＤＢリクエストに含まれる指定セッションは適正であるか否かを判定する。適正である場合、処理をステップＳ８３に進める。適正でない場合、処理をステップＳ８７に進める。なお、ＤＢ処理部１２０は、例えば指定セッションのセッション番号とＡＰサーバ４００のためにプールしたセッションのセッション番号とを照合することで、指定セッションが適正であるか否かを判定することができる。すなわち、ＡＰサーバ４００の指定セッションとＤＢサーバ１００でＡＰサーバ４００用にプールしているセッションとのセッション番号が一致する場合、適正であると判定する。これらが一致しない場合、適正でないと判定する。プールしたセッションの情報は、例えばＡＰサーバの識別情報に対応付けて所定の記憶部に記憶されている。
【０１４１】
［ステップＳ８３］ＤＢ処理部１２０は、ＤＢリクエストに応じたＤＢ処理を実行する。
［ステップＳ８４］ＤＢ処理部１２０は、版数記憶部１１０を参照してクラスタ版数を取得する。
【０１４２】
［ステップＳ８５］ＤＢ処理部１２０は、ＤＢ処理の実行結果に基づいて、クラスタ版数を含むＤＢレスポンスを生成する。
［ステップＳ８６］ＤＢ処理部１２０は、生成したＤＢレスポンスをＡＰ通信部１６０に出力する。ＡＰ通信部１６０は、取得したＤＢレスポンスをＡＰサーバ４００に送信する。なお、このＤＢレスポンスは正常にＤＢ処理がなされた際の応答であるので、正常応答である。
【０１４３】
［ステップＳ８７］ＤＢ処理部１２０は、版数記憶部１１０を参照してクラスタ版数を取得する。ここで、版数記憶部１１０に記憶されたクラスタ版数が所定の初期値（例えば、“−１”）を示している場合は、サービス監視部１４０は新たなクラスタ版数を版数記憶部１１０に設定する。この場合、ＤＢ処理部１２０は、サービス監視部１４０が設定したクラスタ版数を取得する。
【０１４４】
［ステップＳ８８］ＤＢ処理部１２０は、指定セッションが適正でない旨を示すセッション無効通知を生成する。ＤＢ処理部１２０は、セッション無効通知にクラスタ版数を含める。
【０１４５】
［ステップＳ８９］ＤＢ処理部１２０は、セッション無効通知をＡＰ通信部１６０に出力する。ＡＰ通信部１６０は、セッション無効通知およびクラスタ版数をＡＰサーバ４００に送信する。このレスポンスは、正常にＤＢ処理がなされない場合の応答であるので、正常応答ではない。この場合、ＡＰサーバ４００において図１３のステップＳ５４で正常応答と判定されない。
【０１４６】
このようにして、ＤＢサーバ１００はＡＰサーバ４００に対するレスポンスと共に、クラスタ版数を送信する。
なお、ステップＳ８５〜Ｓ８９では、クラスタ版数を各種レスポンスに含めて生成し、送信するものとしたが、これらを別個にＡＰサーバ４００に送信してもよい。例えば、ＡＰ通信部１６０がＡＰサーバ４００に各種レスポンスを送信する際に、版数送信部１５０がＡＰサーバ４００にクラスタ版数を送信することとしてもよい。
【０１４７】
次に、図１３のステップＳ５６に示したＡＰサーバ４００のＤＢレスポンス受信処理を詳細に説明する。
図１７は、第２の実施の形態のＤＢレスポンス受信処理を示すフローチャートである。以下、図１７に示す処理をステップ番号に沿って説明する。
【０１４８】
［ステップＳ９１］ＡＰ処理部４２０は、ＤＢ通信部４６０で正常応答と判定されたＤＢレスポンスを取得する。ＡＰ処理部４２０は、ＤＢレスポンスに応じたＡＰ処理を実行する。ＡＰ処理部４２０は、ＡＰ処理の実行結果に基づいて、端末装置６１へＡＰレスポンスを送信する。
【０１４９】
［ステップＳ９２］セッション制御部４４０は、ＤＢ通信部４６０が受信したクラスタ版数を取得する。
［ステップＳ９３］セッション制御部４４０は、ＤＢレスポンスの送信元クラスタのセッション管理テーブルを参照する。ここでは、セッション情報記憶部４１０に記憶されたセッション管理テーブル４１２を参照する。
【０１５０】
［ステップＳ９４］セッション制御部４４０は、受信したクラスタ版数とセッション取得時版数の異なるレコードが存在するか否かを判定する。存在する場合、処理をステップＳ９５に進める。存在しない場合、処理をステップＳ９６に進める。
【０１５１】
［ステップＳ９５］セッション制御部４４０は、セッション管理テーブル４１２のうち、セッション取得時版数が現クラスタ版数と異なるレコードにつき、無効フラグに“無効”を設定する。
【０１５２】
［ステップＳ９６］セッション制御部４４０は、セッション情報記憶部４１０に記憶された版数管理テーブル４１１のＤＢクラスタ１０（クラスタ名“ＤＢ０００１”）に対応するクラスタ版数に受信したクラスタ版数を設定する。
【０１５３】
このようにして、ＡＰサーバ４００はセッション管理テーブル４１２に含まれるセッションのうち、ＤＢクラスタ１０から受信したクラスタ版数と異なるセッション取得時版数が設定されているセッションが存在する場合、そのセッションを“無効”とする。
【０１５４】
次に、図１３のステップＳ５９に示したＡＰサーバ４００のセッション整理処理を詳細に説明する。
図１８は、第２の実施の形態のセッション整理処理を示すフローチャートである。以下、図１８に示す処理をステップ番号に沿って説明する。
【０１５５】
［ステップＳ１０１］セッション制御部４４０は、端末装置６１に対して割り当てていたセッションを特定する。
［ステップＳ１０２］セッション制御部４４０は、セッション情報記憶部４１０に記憶されたセッション管理テーブル４１２を参照して、そのセッションが有効であるか否かを判定する。有効である場合、処理をステップＳ１０３に進める。無効である場合、処理をステップＳ１０５に進める。
【０１５６】
［ステップＳ１０３］セッション制御部４４０は、セッション管理テーブル４１２に設定されたセッションの総数がプール上限値を超過しているか否かを判定する。未超過の場合、処理をステップＳ１０４に進める。超過している場合、処理をステップＳ１０５に進める。
【０１５７】
［ステップＳ１０４］セッション制御部４４０は、ステップＳ１０１で特定したセッションを未割当とする。すなわち、該当のレコードから端末装置６１の要求元識別情報を削除する。
【０１５８】
［ステップＳ１０５］セッション制御部４４０は、ＤＢクラスタ１０に対してセッション管理テーブル４１２に設定された無効なセッションの破棄を指示する無効セッション破棄要求を生成し、ＤＢ通信部４６０に出力する。ＤＢ通信部４６０は、無効セッション破棄要求をＤＢクラスタ１０に送信する。
【０１５９】
［ステップＳ１０６］ＤＢ通信部４６０は、ＤＢクラスタ１０からステップＳ１０５で指示したセッションを破棄した旨を示す無効セッション破棄応答を受信する。ＤＢ通信部４６０は、破棄応答をセッション制御部４４０に出力する。
【０１６０】
［ステップＳ１０７］セッション制御部４４０は、セッション管理テーブル４１２に含まれる無効セッションのレコードを削除する。
このようにして、ＡＰサーバ４００は端末装置６１，６２，６３，・・・に対してＡＰレスポンスを送信した後に、業務処理のために利用していたＤＢクラスタ１０上のセッションの再利用を可能とする。
【０１６１】
また、ＡＰサーバ４００はセッションを無効とした後、端末装置６１，６２，６３，・・・との一連の通信が完了した後に無効セッションを破棄する。これにより、次のような効果を得ることができる。
【０１６２】
例えば、ＡＰサーバ４００とＤＢクラスタ１０との通信が完了した状態で、業務処理トランザクションは継続しているような場合が発生し得る。この場合、トランザクションにより該当のセッションがロックされていると、そのセッションを破棄しようとしてもエラーとなり、適切にセッションの破棄が行われない場合が生じ得る。
【０１６３】
これに対し、ＡＰサーバ４００は上述のように、端末装置６１，６２，６３，・・・に対してＡＰレスポンスが送信された後（すなわち、業務処理トランザクションが一通り完了して、ＡＰサーバ４００と端末装置６１，６２，６３，・・・一連の通信が完了した後）に無効セッションを破棄するので、確実にセッションの破棄を行うことができる。
【０１６４】
次に、業務処理システムにおける処理の流れの具体例を説明する。なお、以下の例でもＤＢクラスタ１０およびＡＰサーバ４００との間の処理のみを説明するが、ＤＢクラスタ１０とＡＰサーバ５００，６００およびＤＢクラスタ２０，３０とＡＰサーバ４００，５００，６００との間の処理に関しても同様である。
【０１６５】
以下の各図におけるステップの直前では、ＤＢクラスタ１０につきＤＢサーバ１００が運用系、ＤＢサーバ１００ａが待機系の状態であるとする。
図１９は、第２の実施の形態のセッション無効化処理を示す第１のシーケンス図である。以下、図１９に示す処理をステップ番号に沿って説明する。
【０１６６】
［ステップＳＴ１］ＤＢサーバ１００は、ＤＢサービスの停止を開始する。
［ステップＳＴ２］ＤＢサーバ１００は、クラスタ版数を更新する。ＤＢサーバ１００は、ＡＰサーバ４００へクラスタ停止開始通知およびクラスタ版数を送信する。ＡＰサーバ４００は、ＤＢサーバ１００からクラスタ停止開始通知およびクラスタ版数を受信する。
【０１６７】
［ステップＳＴ３］ＡＰサーバ４００は、セッション無効化処理を実行する。ＡＰサーバ４００は、ＤＢクラスタ１０を“非運用中”とする。これにより、ＤＢクラスタ１０はＤＢ処理の振り分け対象外となる。
【０１６８】
［ステップＳＴ４］ＤＢサーバ１００ａは、ＤＢサーバ１００からのハートビートパケットの受信が途絶えたことを検知する。
［ステップＳＴ５］ＤＢサーバ１００ａは、ＤＢサービスの起動を開始する。
【０１６９】
［ステップＳＴ６］ＤＢサーバ１００ａは、ＤＢサービスの起動を完了する。ＤＢサーバ１００ａが現用系となる。仮想ＤＢアドレスの担い手がＤＢサーバ１００ａに切り替わる。すなわち、外部装置との仮想ＤＢアドレスを介したデータ通信はＤＢサーバ１００ａにより行われるようになる。
【０１７０】
［ステップＳＴ７］ＤＢサーバ１００ａは、クラスタ版数を更新する。ＤＢサーバ１００ａは、ＡＰサーバ４００へクラスタ起動完了通知およびクラスタ版数を送信する。ＡＰサーバ４００は、ＤＢサーバ１００ａからクラスタ起動完了通知およびクラスタ版数を受信する。
【０１７１】
［ステップＳＴ８］ＡＰサーバ４００は、セッション無効化処理を実行する。ＡＰサーバ４００は、ＤＢクラスタ１０を“運用中”とする。これにより、ＤＢクラスタ１０はＤＢ処理の振り分け対象となる。
【０１７２】
［ステップＳＴ９］ＡＰサーバ４００は、端末装置６１からＡＰリクエストを受信すると、ＤＢ処理の振り分け先としてＤＢクラスタ１０を選択する。そして、ＡＰサーバ４００は、ＤＢリクエスト送信のためにセッション開設要求をＤＢクラスタ１０に送信する。
【０１７３】
このように、ＤＢクラスタ１０はクラスタ切替の開始時およびクラスタ切替の完了時に、各処理の段階を示す旨の通知をＡＰサーバ４００，５００，６００に送信する。
これにより、ＡＰサーバ４００，５００，６００は、ＤＢクラスタ１０におけるクラスタ切替の開始・完了を適正に検知できる。ＡＰサーバ４００，５００，６００は、ステップＳＴ２〜ＳＴ８の間ではＤＢクラスタ１０に処理を振り分けないので、クラスタ切替中のＤＢクラスタ１０に対する無駄なＤＢリクエストの送信を抑制できる。
【０１７４】
また、ＤＢクラスタ１０は、クラスタ切替の開始時およびクラスタ切替の完了時にクラスタ版数を送信する。そして、ＡＰサーバ４００，５００，６００は更新されたクラスタ版数を受信した場合、ＤＢクラスタ１０から割り当てられていたセッションを無効とする。したがって、ＤＢクラスタ１０が利用可能となった際に、ＡＰサーバ４００，５００，６００は、ＤＢクラスタ１０との通信開始時に利用可能なセッションが存在しないこととなる。よって、ＡＰサーバ４００，５００，６００は、ＤＢクラスタ１０との間でデータ通信を行う際には、まず、ＤＢクラスタ１０に新規セッションの開設を要求する。
【０１７５】
これにより、クラスタ切替直後にＤＢサーバ１００ａでプールされていないセッションを指定したＤＢリクエストがＡＰサーバ４００，５００，６００からＤＢサーバ１００ａに送信されることがない。よって、ＡＰサーバ側とＤＢサーバ側とのセッション不整合によるエラーの発生を抑止することができる。
【０１７６】
また、ＤＢクラスタ１０に含まれるＤＢサーバ１００，１００ａで一貫した版数を用いてＤＢクラスタ１０の状態を管理する。このため、ＡＰサーバ４００では受信元をクラスタ単位のＤＢ仮想アドレスで識別できればよく、その配下のＤＢサーバを意識しなくてよい。このため、仮想アドレスの配下に存在するサーバとの間で確立するセッションの管理を容易に行うことができる。
【０１７７】
更に、ＤＢクラスタ１０はクラスタ切替の開始時と完了時とにクラスタ版数を更新して送信する。このため、仮にクラスタ切替の開始時にＤＢサーバ１００の障害等が原因で、クラスタ版数がＡＰサーバ側に到達しなかった場合にも、クラスタ切替の完了時のクラスタ版数の通知によってＡＰサーバ側で確実にセッションの無効化が実行される。次に、そのような場合を例示する。
【０１７８】
図２０は、第２の実施の形態のセッション無効化処理を示す第２のシーケンス図である。以下、図２０に示す処理をステップ番号に沿って説明する。
［ステップＳＴ１１］ＤＢサーバ１００は、障害によりＤＢサービスが利用不可となる。
【０１７９】
［ステップＳＴ１２］ＤＢサーバ１００ａは、ＤＢサーバ１００からのハートビートパケットの受信が途絶えたことを検知する。
［ステップＳＴ１３］ＤＢサーバ１００ａは、ＤＢサービスの起動を開始する。
【０１８０】
［ステップＳＴ１４］ＤＢサーバ１００ａは、ＤＢサービスの起動を完了する。ＤＢサーバ１００ａが現用系となる。仮想ＤＢアドレスの担い手がＤＢサーバ１００ａに切り替わる。すなわち、外部装置との仮想ＤＢアドレスを介したデータ通信はＤＢサーバ１００ａにより行われるようになる。
【０１８１】
［ステップＳＴ１５］ＤＢサーバ１００ａは、クラスタ版数を更新する。ＤＢサーバ１００ａは、ＡＰサーバ４００へクラスタ版数およびクラスタ起動完了通知を送信する。ＡＰサーバ４００は、ＤＢサーバ１００ａからクラスタ版数およびクラスタ起動完了通知を受信する。
【０１８２】
［ステップＳＴ１６］ＡＰサーバ４００は、セッション無効化処理を実行する。ＡＰサーバ４００は、ＤＢクラスタ１０を“運用中”とする。これにより、ＤＢクラスタ１０はＤＢ処理の振り分け対象となる。
【０１８３】
［ステップＳＴ１７］ＡＰサーバ４００は、端末装置６１からＡＰリクエストを受信すると、ＤＢ処理の振り分け先としてＤＢクラスタ１０を選択する。そして、ＡＰサーバ４００は、ＤＢリクエスト送信のためにセッション開設要求をＤＢクラスタ１０に送信する。
【０１８４】
このように、ＤＢクラスタ１０はＤＢサーバ１００の障害によって、クラスタ切替開始時にクラスタ版数をＡＰサーバ４００，５００，６００に送信できなかった場合にも、ＡＰサーバ４００，５００，６００に確実にセッションの無効化処理を促すことができる。
【０１８５】
次に、クラスタ切替の完了後、ＤＢクラスタ１０がＡＰサーバ４００，５００，６００にクラスタ起動完了通知を送信する前にＡＰサーバ４００からＤＢリクエストを受信する場合を例示する。
【０１８６】
図２１は、第２の実施の形態のセッション無効化処理を示す第３のシーケンス図である。以下、図２１に示す処理をステップ番号に沿って説明する。
［ステップＳＴ２１］ＤＢサーバ１００は、障害によりＤＢサービスが利用不可となる。
【０１８７】
［ステップＳＴ２２］ＤＢサーバ１００ａは、ＤＢサーバ１００からのハートビートパケットの受信が途絶えたことを検知する。
［ステップＳＴ２３］ＤＢサーバ１００ａは、ＤＢサービスの起動を開始する。
【０１８８】
［ステップＳＴ２４］ＤＢサーバ１００ａは、ＤＢサービスの起動を完了する。ＤＢサーバ１００ａが現用系となる。仮想ＤＢアドレスの担い手がＤＢサーバ１００ａに切り替わる。すなわち、外部装置との仮想ＤＢアドレスを介したデータ通信はＤＢサーバ１００ａにより行われるようになる。
【０１８９】
［ステップＳＴ２５］ＡＰサーバ４００は、クラスタ切替前にＤＢサーバ１００から払い出されたセッションを指定して、ＤＢクラスタ１０にＤＢリクエストを送信する。ＤＢサーバ１００ａは、ＡＰサーバ４００からＤＢリクエストを受信する。
【０１９０】
［ステップＳＴ２６］ＤＢサーバ１００ａは、クラスタ版数が初期値であるため、新たにクラスタ版数を設定する。ＤＢサーバ１００ａは、セッション無効通知およびこのクラスタ版数をＡＰサーバ４００に送信する。ＡＰサーバ４００は、ＤＢサーバ１００ａからセッション無効通知およびクラスタ版数を受信する。
【０１９１】
［ステップＳＴ２７］ＡＰサーバ４００は、セッション無効化処理を実行する。
［ステップＳＴ２８］ＡＰサーバ４００は、端末装置６１からＡＰリクエストを受信すると、ＤＢ処理の振り分け先としてＤＢクラスタ１０を選択する。そして、ＡＰサーバ４００は、ＤＢリクエスト送信のためにセッション開設要求をＤＢクラスタ１０に送信する。
【０１９２】
このように、障害等でクラスタ停止開始通知がＡＰサーバ４００，５００，６００に送信されない場合には、クラスタ切替直後にＤＢサーバ１００ａでプールされていないセッションを指定したＤＢリクエストがＤＢサーバ１００ａに送信されることも考えられる。
【０１９３】
これに対し、ＤＢサーバ１００ａはそのようなＤＢリクエストに対して、セッション無効通知およびクラスタ版数を応答する。このため、ＡＰサーバ４００はＤＢクラスタ１０との間でプールされたセッションが無効であると検知できる。
【０１９４】
なお、上述の例では、ＤＢサーバ１００ａはステップＳＴ２６でＤＢリクエストに対してセッション無効通知およびクラスタ版数の応答を行う。これによって、ＡＰサーバ４００ではセッション無効通知によるセッションの無効化処理が行われるので、その後にＤＢサービス起動時版数通知処理を行わないものとした。ただし、ＤＢサーバ１００ａはＤＢサービス起動時版数通知処理を実行してもよい。その場合、クラスタ版数が更新されるので、ＡＰサーバ４００ではステップＳＴ２７のセッション無効化処理とは別に再度セッション無効化処理が行われる。
【０１９５】
以上で説明したように、本実施の形態の業務処理システムによればＡＰサーバ側とＤＢサーバ側とのセッション不整合によるエラーの発生を抑止することができる。
例えば、クラスタ構成を採る基幹システムでクラスタ切替が発生し、エラーが発生するような場合でも、クライアント装置側（端末装置６１，６２，６３，・・・）では端末エラーが表示されなくなる。その結果、多数のクライアント装置側に旧いセッションエラーが表示されて業務が中断し、現場が混乱する等の問題を解消することができる。
【０１９６】
［第３の実施の形態］
以下、第３の実施の形態について説明する。前述の第２の実施の形態との相違点を中心に説明し、同様の事項については説明を省略する。
【０１９７】
ここで、第２の実施の形態ではＡＰサーバ側でＤＢクラスタ側のクラスタ版数を管理することとした。第３の実施の形態では、更にＤＢクラスタ側でＡＰサーバ側の版数（サーバ版数）を管理する。以下では、それによって実現される機能について説明する。
【０１９８】
なお、第３の実施の形態の業務処理システムの構成は、図２に示した第２の実施の形態の業務処理システムの構成と同様であるため説明を省略する。更に、第３の実施の形態の業務処理システムの各装置のハードウェア構成は、図３に示した第２の実施の形態のＤＢサーバ１００のハードウェア構成と同様であるため、説明を省略する。
【０１９９】
また、以下の説明では第２の実施の形態の各装置に付した符号と同一の符号を用いて、第３の実施の形態の各装置を説明する。
図２２は、第３の実施の形態のＤＢサーバの機能構成を示す図である。ＤＢサーバ１００は、版数記憶部１１０、ＤＢ処理部１２０、クラスタ制御部１３０、サービス監視部１４０、ＡＰ通信部１６０、セッション情報記憶部１７０、セッション制御部１８０および版数送受信部１９０を有する。これらの機能はＣＰＵ１０１が所定のプログラムを実行することで実現される。なお、これらの機能の全部あるいは少なくとも一部を専用のハードウェアを用いて実現してもよい。
【０２００】
ここで、版数記憶部１１０、ＤＢ処理部１２０、クラスタ制御部１３０、サービス監視部１４０およびＡＰ通信部１６０は、図４で同一の符号を用いて説明した各構成と同一であるため説明を省略する。
【０２０１】
ただし、クラスタ制御部１３０は、版数記憶部１１０、ＤＢ処理部１２０、サービス監視部１４０、ＡＰ通信部１６０、セッション情報記憶部１７０、セッション制御部１８０および版数送受信部１９０の各機能の起動・停止を制御する。すなわち、クラスタ制御部１３０は、ＤＢサーバ１００ａが待機系として動作する場合、自サーバを現用系として動作させるためにこれらの各機能を起動させる。
【０２０２】
セッション情報記憶部１７０は、ＡＰサーバ４００のセッション情報記憶部４１０に対応する。セッション情報記憶部１７０はＡＰサーバ４００，５００，６００のサーバ版数を記憶する。サーバ版数の詳細は後述する。セッション情報記憶部４１０は、ＡＰサーバ４００，５００，６００に対して割り当てたセッションを定義したセッション情報を記憶する。
【０２０３】
セッション制御部１８０は、セッション情報記憶部１７０に記憶されたＡＰサーバ４００，５００，６００のサーバ版数およびセッション情報を管理する。
版数送受信部１９０は、サービス監視部１４０により版数記憶部１１０に記憶されたクラスタ版数が更新されると、そのクラスタ版数をＡＰサーバ４００，５００，６００に送信する。また、版数送受信部１９０は、ＡＰサーバ４００，５００，６００から各サーバのサーバ版数を受信する。版数送受信部１９０は、受信したサーバ版数をセッション制御部１８０に出力する。
【０２０４】
ＤＢサーバ１００ａは、版数記憶部１１０ａ、ＤＢ処理部１２０ａ、クラスタ制御部１３０ａ、サービス監視部１４０ａ、ＡＰ通信部１６０ａ、セッション情報記憶部１７０ａ、セッション制御部１８０ａおよび版数送受信部１９０ａを有する。これらの機能は、ＤＢサーバ１００ａが備えるＣＰＵが所定のプログラムを実行することで実現される。なお、これらの機能の全部あるいは少なくとも一部を専用のハードウェアを用いて実現してもよい。
【０２０５】
ここで、版数記憶部１１０ａ、ＤＢ処理部１２０ａ、クラスタ制御部１３０ａ、サービス監視部１４０ａおよびＡＰ通信部１６０ａは、図４で同一の符号を用いて説明した各構成と同一であるため説明を省略する。
【０２０６】
ただし、クラスタ制御部１３０ａは、ＤＢサーバ１００が現用系として動作している場合には、これらの機能の停止状態を維持する。一方、ＤＢサーバ１００が利用不可となった場合には、自サーバを現用系として動作させるためにこれらの各機能を起動させる。
【０２０７】
セッション情報記憶部１７０ａは、セッション情報記憶部１７０に対応する。セッション制御部１８０ａは、セッション制御部１８０に対応する。版数送受信部１９０ａは、版数送受信部１９０に対応する。
【０２０８】
また、ＤＢクラスタ２０，３０についてもＤＢクラスタ１０と同様の機能構成により実現できる。
図２３は、第３の実施の形態のＡＰサーバの機能構成を示す図である。ＡＰサーバ４００は、セッション情報記憶部４１０、ＡＰ処理部４２０、クライアント通信部４３０、セッション制御部４４０、ＤＢ通信部４６０、版数記憶部４７０、サービス監視部４８０および版数送受信部４９０を有する。これらの機能は、ＡＰサーバ４００が備えるＣＰＵが所定のプログラムを実行することで実現される。なお、これらの機能の全部あるいは少なくとも一部を専用のハードウェアを用いて実現してもよい。
【０２０９】
ここで、セッション情報記憶部４１０、ＡＰ処理部４２０、クライアント通信部４３０、セッション制御部４４０、ＤＢ通信部４６０は、図５で同一の符号を用いて説明した各構成と同一であるため説明を省略する。
【０２１０】
版数記憶部４７０は、ＡＰサーバ４００のサーバ版数を記憶する。
サービス監視部４８０は、ＡＰ処理部４２０の起動・停止を監視する。サービス監視部４８０は、ＡＰ処理部４２０が起動または停止した場合に、版数記憶部４７０に記憶されたサーバ版数を更新する。
【０２１１】
版数送受信部４９０は、サービス監視部４８０により版数記憶部４７０に記憶されたサーバ版数が更新されると、そのサーバ版数をＤＢクラスタ１０，２０，３０に送信する。また、版数送受信部４９０は、ＤＢクラスタ１０，２０，３０から各クラスタのクラスタ版数を受信する。版数送受信部４９０は、受信したクラスタ版数をセッション制御部４４０に出力する。
【０２１２】
なお、ＡＰサーバ５００，６００に関してもＡＰサーバ４００と同様の機能構成により実現できる。
図２４は、ＤＢサーバが有する版数管理テーブルのデータ構造例を示す図である。版数管理テーブル１７１は、セッション制御部１８０により更新され、セッション情報記憶部１７０に格納される。版数管理テーブル１７１には、ＡＰサーバ名を示す項目、サーバ版数を示す項目および運用状態を示す項目が設けられている。各項目の横方向に並べられた情報同士が互いに関連付けられて、１つのＡＰサーバに関する情報を示す。
【０２１３】
ＡＰサーバ名を示す項目には、ＡＰサーバのサーバ名を示す情報が設定される。サーバ版数を示す項目には、ＡＰサーバのサーバ版数を示す情報が設定される。運用状態を示す項目には、運用中であるか否かを示す情報が設定される。
【０２１４】
版数管理テーブル１７１には、例えばＡＰサーバ名が“ＡＰ０００１”、サーバ版数が“１２５７０４１５５２”、運用状態が“運用中”という情報が設定される。これは、クラスタ名“ＡＰ０００１”で示されるＡＰサーバ４００のサーバ版数が“１２５７０４１５５２”であることを示している。また、ＡＰサーバ４００は、現在“運用中”であることを示している。
【０２１５】
ここで、以下ではＡＰサーバ５００のＡＰサーバ名を“ＡＰ０００２”、ＡＰサーバ６００のＡＰサーバ名を“ＡＰ０００３”とする。
図２５は、ＤＢサーバが有するセッション管理テーブルのデータ構造例を示す図である。セッション管理テーブル１７２，１７３，１７４は、セッション制御部１８０により更新され、セッション情報記憶部１７０に格納される。セッション管理テーブル１７２はＡＰサーバ４００に割り当てたセッションを管理するためのものである。セッション管理テーブル１７３はＡＰサーバ５００に割り当てたセッションを管理するためのものである。セッション管理テーブル１７４はＡＰサーバ６００に割り当てたセッションを管理するためのものである。以下では、セッション管理テーブル１７２に関してのみ説明するが、セッション管理テーブル１７３，１７４に関しても同様の構成である。
【０２１６】
セッション管理テーブル１７２には、エントリＩＤを示す項目、セッション割当時版数を示す項目、セッション番号を示す項目および要求先識別情報を示す項目が設けられている。各項目の横方向に並べられた情報同士が互いに関連付けられて、１つのセッションに関する情報を示す。
【０２１７】
エントリＩＤを示す項目には、セッション管理テーブル１７２に含まれる１レコードを識別するためのエントリＩＤが設定される。セッション割当時版数を示す項目には、セッションを割り当てた際のサーバ版数が設定される。セッション番号を示す項目には、ＡＰサーバ４００に割り当てたセッションを識別するためのセッション番号が設定される。要求先識別情報を示す項目には、処理要求を実行するためのスレッドを識別する情報が設定される。
【０２１８】
セッション管理テーブル１７２は、例えばエントリＩＤが“１”、セッション割当時版数が“１２５７０４１５５２”、セッション番号が“４”、要求先識別情報が“スレッド５”という情報が設定される。これは、ＡＰサーバ４００から受け付けたセッション番号“４”を指定する処理要求につき、そのセッションを割り当てた際のＡＰサーバ４００のサーバ版数が“１２５７０４１５５２”であることを示している。また、その処理要求に対する処理を行うスレッドが要求先識別情報“スレッド５”のスレッドであることを示している。
【０２１９】
図２６は、ＡＰサーバが有するサーバ版数テーブルのデータ構造例を示す図である。サーバ版数テーブル４７１は、サービス監視部４８０により更新され、版数記憶部４７０に格納される。サーバ版数テーブル４７１には、ＡＰサーバ４００のサーバ版数が設定される。
【０２２０】
サーバ版数テーブル４７１には、例えば“１２５７０４３８７１”という情報が設定される。これは、図６で説明したクラスタ版数テーブル１１１と同様に、１９７０年１月１日０時０分０秒からの秒数である。サービス監視部４８０はサーバ版数テーブル４７１を更新する際に、例えばＯＳからこのような時間情報をサーバ版数として取得できる。
【０２２１】
なお、サーバ版数はＡＰサービス起動中から起動直後の時点では所定の初期値（例えば“−１”）が設定されるものとする。そして、起動完了後の所定のタイミングで、サービス監視部４８０により、現在の時間情報がサーバ版数として設定される。
【０２２２】
次に、以上のような構成を備える業務処理システムの処理手順を説明する。ここで、以下ではＤＢクラスタ１０およびＡＰサーバ４００に注目して処理手順を説明する。ただし、ＤＢクラスタ１０とＡＰサーバ５００，６００との間の処理も同様である。また、ＤＢクラスタ２０，３０とＡＰサーバ４００，５００，６００との間の処理も同様である。
【０２２３】
まず、ＡＰサーバ４００，５００，６００を縮退運転する。縮退運転とは、ＡＰサーバ４００，５００，６００の何れか一部でＡＰサービスを停止させて業務処理システムを稼働させることを意味する。以下の説明では、ＡＰサーバ４００でＡＰサービスを停止・起動させる場合を例示する。また、ＤＢクラスタ１０はＤＢサーバ１００が現用系、ＤＢサーバ１００ａが待機系であるとする。
【０２２４】
図２７は、第３の実施の形態のＡＰサーバの縮退開始／縮退解除処理を示すシーケンス図である。以下、図２７に示す処理をステップ番号に沿って説明する。
［ステップＳ１１１］ＡＰサーバ４００は、ＡＰサービス（ＡＰ処理部４２０）の停止指示を受け付ける。ＡＰ処理部４２０の停止指示を受け付ける場合としては、例えばシステム管理者がメンテナンスのためにサービス停止を指示する操作入力をＡＰサーバ４００に対して行った場合等が考えられる。また、例えば夜間や休日等、システムの利用の少ない期間に縮退運転するためにＡＰサーバ４００を計画停止させる場合も考えられる。
【０２２５】
［ステップＳ１１２］ＡＰサーバ４００は、ＡＰ処理部４２０の停止を開始する。
［ステップＳ１１３］ＡＰサーバ４００は、ＡＰ処理部４２０の停止が開始されると、版数記憶部４７０に記憶されたサーバ版数を更新する。ＡＰサーバ４００は、更新したサーバ版数およびＡＰサービス停止開始通知をＤＢクラスタ１０，２０，３０に送信する。
【０２２６】
［ステップＳ１１４］ＤＢサーバ１００は、ＡＰサーバ４００からサーバ版数を受信する。ＡＰサーバ４００は、受信したサーバ版数に基づいて、ＤＢサーバ１００がＡＰサーバ４００に割り当てていたセッションの解放処理を実行する。また、ＤＢサーバ１００は、ＡＰサービス停止開始通知を受信したことにより、セッション情報記憶部１７０に記憶された版数管理テーブル１７１のうち、ＡＰサーバ４００（ＡＰサーバ名“ＡＰ０００１”）の運用状態を“非運用中”に設定する。
【０２２７】
［ステップＳ１１５］ＡＰサーバ４００は、ＡＰ処理部４２０の停止が完了する。
［ステップＳ１１６］ＡＰサーバ４００は、メンテナンスの完了に伴う起動指示や計画停止からの復旧のための起動指示によってＡＰ処理部４２０の起動を開始する。
【０２２８】
［ステップＳ１１７］ＡＰサーバ４００は、ＡＰ処理部４２０の起動を完了する。
［ステップＳ１１８］ＡＰサーバ４００は、ＡＰ処理部４２０の起動が完了すると、版数記憶部４７０に記憶されたサーバ版数を更新する。ＡＰサーバ４００は、更新したサーバ版数およびＡＰサービス開始完了通知をＤＢクラスタ１０，２０，３０に送信する。
【０２２９】
［ステップＳ１１９］ＤＢサーバ１００は、ＡＰサーバ４００からサーバ版数を受信する。ＤＢサーバ１００は、受信したサーバ版数に基づいて、ＤＢサーバ１００がＡＰサーバ４００に割り当てていたセッションの解放処理を実行する。また、ＤＢサーバ１００は、ＡＰサービス開始完了通知を受信したことにより、セッション情報記憶部１７０に記憶された版数管理テーブル１７１のうち、ＡＰサーバの運用状態を“運用中”に設定する。
【０２３０】
［ステップＳ１２０］ＤＢサーバ１００は、新たに起動したＡＰサーバ４００にクラスタ版数を送信する。これは、ＤＢクラスタ１０が現在利用可能であることをＡＰサーバ４００に通知するためである。
【０２３１】
このようにして、ＡＰサーバ４００はＡＰサービス停止時および開始時にサーバ版数をＤＢクラスタ１０に送信する。
次に、図２７のステップＳ１１３に示したＤＢクラスタ１０のＤＢサービス停止時版数通知処理を詳細に説明する。
【０２３２】
図２８は、第３の実施の形態のＡＰサービス停止時版数通知処理を示すフローチャートである。以下、図２８に示す処理をステップ番号に沿って説明する。
［ステップＳ１２１］サービス監視部４８０は、ＡＰ処理部４２０の停止開始を検知する。
【０２３３】
［ステップＳ１２２］サービス監視部４８０は、ＯＳから現在のタイムスタンプをサーバ版数として取得する。
［ステップＳ１２３］サービス監視部４８０は、版数記憶部４７０に記憶されたサーバ版数テーブル４７１のサーバ版数をステップＳ１２２で取得したサーバ版数に更新する。
【０２３４】
［ステップＳ１２４］版数送受信部４９０は、サーバ版数テーブル４７１を参照してサーバ版数を取得し、ＤＢクラスタ１０，２０，３０に送信する。また、版数送受信部４９０は、サーバ版数と共に、ＡＰサーバ４００のＡＰサービス停止開始通知をＤＢクラスタ１０，２０，３０に送信する。
【０２３５】
このようにして、ＡＰサーバ４００は、ＡＰ処理部４２０を停止する際にサーバ版数を更新する。そして、ＡＰサーバ４００は、更新後のサーバ版数をＤＢクラスタ１０，２０，３０に送信する。
【０２３６】
次に、図２７のステップＳ１１８に示したＡＰサーバ４００のＡＰサービス起動時版数通知処理を詳細に説明する。
図２９は、第３の実施の形態のＡＰサービス起動時版数通知処理を示すフローチャートである。以下、図２９に示す処理をステップ番号に沿って説明する。
【０２３７】
［ステップＳ１３１］サービス監視部４８０は、ＡＰ処理部４２０の起動完了を検知する。
［ステップＳ１３２］サービス監視部４８０は、ＯＳから現在のタイムスタンプをサーバ版数として取得する。
【０２３８】
［ステップＳ１３３］サービス監視部４８０は、版数記憶部４７０に記憶されたサーバ版数テーブル４７１のサーバ版数を、ステップＳ１３２で取得した版数に更新する。
［ステップＳ１３４］版数送受信部４９０は、サーバ版数テーブル４７１を参照してサーバ版数を取得し、ＤＢクラスタ１０，２０，３０に送信する。また、版数送受信部４９０は、サーバ版数と共に、ＡＰサーバ４００のＡＰサービス起動完了通知をＤＢクラスタ１０，２０，３０に送信する。
【０２３９】
このようにして、ＡＰサーバ４００は、ＡＰサービスを開始する際にサーバ版数を更新する。そして、ＡＰサーバ４００は、更新後のサーバ版数をＤＢクラスタ１０，２０，３０に送信する。
【０２４０】
次に、図２７のステップＳ１１４，Ｓ１１９に示したＤＢサーバ１００のセッション解放処理を詳細に説明する。
図３０は、第３の実施の形態のセッション解放処理を示すフローチャートである。以下、図３０に示す処理をステップ番号に沿って説明する。
【０２４１】
［ステップＳ１４１］版数送受信部１９０は、ＡＰサーバ４００からサーバ版数を受信する。版数送受信部１９０は、受信したサーバ版数をセッション制御部１８０に出力する。
【０２４２】
［ステップＳ１４２］セッション制御部１８０は、セッション情報記憶部１７０に記憶されたセッション管理テーブル１７２を参照して、ＡＰサーバ４００に割り当てたセッションを定義したレコードを特定する。
【０２４３】
［ステップＳ１４３］セッション制御部１８０は、特定したレコードのうち、ステップＳ１４１で受信したサーバ版数とセッション割当時版数とが異なるレコードが存在するか否かを判定する。存在する場合、処理をステップＳ１４４に進める。存在しない場合、処理を完了する。
【０２４４】
［ステップＳ１４４］セッション制御部１８０は、セッション取得時版数が新たに受信したサーバ版数と異なるレコードに対応する要求先識別情報を取得する。そして、セッション制御部１８０は、その要求先識別情報で指定されるスレッドに停止シグナルを発行する。
【０２４５】
［ステップＳ１４５］セッション制御部１８０は、セッション取得時版数が新たに受信したサーバ版数と異なるレコードで示されるセッションを解放する。すなわち、該当のセッションは何れのＡＰサーバおよびスレッドにも割り当てられていない空きの状態となり、再利用が可能となる。
【０２４６】
［ステップＳ１４６］セッション制御部１８０は、セッション情報記憶部１７０に記憶された版数管理テーブル１７１のＡＰサーバ４００のサーバ版数として、ステップＳ１４１で受信したサーバ版数を設定する。
【０２４７】
このようにして、セッション制御部１８０は、ＡＰサーバ４００から受信したサーバ版数とセッション割当時版数とが異なる場合、該当のセッションを解放する。
次に、業務処理システムで実行される業務処理の手順を説明する。
【０２４８】
図３１は、第３の実施の形態の業務処理を示すシーケンス図である。以下、図３１に示す処理をステップ番号に沿って説明する。
［ステップＳ１５１］ＡＰサーバ４００は、端末装置６１から業務処理要求（以下、ＡＰリクエストという）を受信する。
【０２４９】
［ステップＳ１５２］ＡＰサーバ４００は、取得したＡＰリクエストに応じた業務処理を実行する。ＡＰサーバ４００は、業務処理に応じてＤＢクラスタに依頼すべき処理が発生した場合、処理要求（以下、ＤＢリクエストという）を生成する。ＡＰサーバ４００は、生成したＤＢリクエストを送信すべきＤＢクラスタを選択する。選択の方法は、第２の実施の形態で説明した方法と同様である（例えば、ラウンドロビンである）。ここでは、ＡＰサーバ４００はＤＢクラスタ１０を選択するものとする。そして、ＤＢクラスタ１０にＤＢリクエストを送信する。このとき、ＡＰサーバ４００は、ＤＢリクエストにＡＰサーバ４００のサーバ版数を含める。
【０２５０】
［ステップＳ１５３］ＤＢサーバ１００は、ＡＰサーバ４００からＤＢリクエストを受信する。ＤＢサーバ１００は、受信したＤＢリクエストに含まれるサーバ版数に基づいて、ＡＰサーバ４００に現在割り当てているセッションが有効であるかを判定する。有効である場合、ＤＢサーバ１００は、受信したＤＢリクエストに基づいてＤＢ処理を実行する。ＤＢサーバ１００は、ＤＢ処理の結果に基づいてＤＢレスポンスを生成し、クラスタ版数と共にＡＰサーバ４００に送信する。
【０２５１】
［ステップＳ１５４］ＡＰサーバ４００は、ＤＢレスポンスを受信する。ＡＰサーバ４００は、ＤＢレスポンスが正常応答であるか否かを判定する。正常応答でない場合、処理をステップＳ１５５に進める。正常応答である場合、処理をステップＳ１５６に進める。
【０２５２】
［ステップＳ１５５］ＡＰサーバ４００は、セッション無効化処理を実行する。セッション無効化処理は、図１２に示す処理と同様である。そして、処理をステップＳ１５２に進める。
【０２５３】
［ステップＳ１５６］ＡＰサーバ４００は、ＤＢレスポンス受信処理を実行する。ＤＢレスポンス受信処理は、図１７に示した第２の実施の形態のＤＢレスポンス受信処理の手順と同様である。
【０２５４】
［ステップＳ１５７］ＡＰサーバ４００は、必要に応じて、ＤＢレスポンスに応じた業務処理を更に実行し、端末装置６１に対するＡＰレスポンスを生成する。そして、ＡＰサーバ４００は、生成したＡＰレスポンスを端末装置６１に送信する。
【０２５５】
［ステップＳ１５８］ＡＰサーバ４００は、端末装置６１との一連の通信が完了したことを検知する。
［ステップＳ１５９］ＡＰサーバ４００は、端末装置６１との通信用として管理していた（ＡＰサーバ４００とＤＢクラスタとの間の）セッションを整理するための処理を実行する。セッション整理処理は、図１８に示した第２の実施の形態のセッション整理処理の手順と同様である。
【０２５６】
このようにして、ＡＰサーバ４００とＤＢクラスタ１０との間で業務処理に伴う通信が行われる。
次に、図３１のステップＳ１５２に示したＡＰサーバ４００のＤＢリクエスト送信処理を説明する。
【０２５７】
図３２は、第３の実施の形態のＤＢリクエスト送信処理を示すフローチャートである。以下、図３２に示す処理をステップ番号に沿って説明する。
［ステップＳ１６１］ＡＰ処理部４２０は、ＡＰリクエストに応じた業務処理の実行に伴って、ＤＢクラスタに依頼すべき処理内容を記述したＤＢリクエストを生成する。ＡＰ処理部４２０は、版数記憶部４７０に記憶されたサーバ版数テーブル４７１を参照してサーバ版数を取得する。ＡＰ処理部４２０は、取得したサーバ版数をＤＢリクエストに含める。ＡＰ処理部４２０は、生成したＤＢリクエストをＤＢ通信部４６０に出力する。
【０２５８】
［ステップＳ１６２］セッション制御部４４０は、セッション情報記憶部４１０に記憶された版数管理テーブル４１１を参照する。
［ステップＳ１６３］セッション制御部４４０は、運用状態が“運用中”のＤＢクラスタが存在するか否かを判定する。“運用中”のＤＢクラスタが存在する場合、処理をステップＳ１６４に進める。“運用中”のＤＢクラスタが存在しない場合、処理を完了させる。なお、“運用中”のＤＢクラスタが存在しない場合、その後、ＡＰ処理部４２０は、クライアント通信部４３０を介して端末装置６１にエラーを応答し、業務処理を完了させる。
【０２５９】
［ステップＳ１６４］セッション制御部４４０は、“運用中”のＤＢクラスタを選択する。選択の方法は、第２の実施の形態で説明した方法と同様である（例えば、ラウンドロビンである）。
【０２６０】
［ステップＳ１６５］セッション制御部４４０は、選択したＤＢクラスタにつきセッション割当処理を実行する。すなわち、ＤＢ通信部４６０が該当のＤＢクラスタにＤＢリクエストを送信するためのセッションを割り当てる。このとき、例えば該当のＤＢクラスタから予め取得したセッションに空きがなければ、該当のＤＢクラスタにセッションの開設を要求する。そして、ＤＢクラスタから新規セッションの払い出しを受けられれば、そのセッションをＤＢリクエスト送信に割り当てることができる。また、セッションの払い出しを受けられなければ、セッションを割り当てることはできない。
【０２６１】
［ステップＳ１６６］セッション制御部４４０は、ＤＢリクエストを送信するためのセッションを割り当てることができたか否かを判定する。割り当てることができた場合、処理をステップＳ１６７に進める。割り当てることができなかった場合、処理をステップＳ１６３に進める。
【０２６２】
［ステップＳ１６７］ＤＢ通信部４６０は、セッション制御部４４０により割り当てられたセッション番号（指定セッションの番号）をＤＢリクエストに含める。そして、ＤＢ通信部４６０はセッション制御部４４０が選択したＤＢクラスタに対し、ＤＢリクエストを送信する。
【０２６３】
このようにして、ＡＰサーバ４００はＤＢリクエストを送信する際に、送信すべきＤＢクラスタを選択し、そのＤＢクラスタとの通信に用いるセッションを割り当てる。このとき、ＡＰサーバ４００はＤＢリクエストにサーバ版数を含める。
【０２６４】
なお、ＡＰサーバ４００は、ＤＢリクエストとサーバ版数とを別個に送信してもよい。例えば、ＤＢ通信部４６０がＤＢリクエストをＤＢクラスタ１０に送信する際に、版数送受信部４９０がサーバ版数をＤＢクラスタ１０に送信することとしてもよい。
【０２６５】
次に、図３２のステップＳ１６５に示したＡＰサーバ４００のセッション割当処理を詳細に説明する。
図３３は、第３の実施の形態のセッション割当処理を示すフローチャートである。以下、図３３に示す処理をステップ番号に沿って説明する。
【０２６６】
［ステップＳ１７１］セッション制御部４４０は、セッション情報記憶部４１０に記憶されたセッション管理テーブル４１２を参照する。
［ステップＳ１７２］セッション制御部４４０は、セッション管理テーブル４１２にエントリされたセッションのうち、何れの端末装置にも割り当てられていない未割当セッションが存在するか否かを判定する。未割当セッションが存在する場合、処理をステップＳ１７３に進める。未割当セッションが存在しない場合、処理をステップＳ１７６に進める。
【０２６７】
［ステップＳ１７３］セッション制御部４４０は、未割当セッションのうち、有効である（すなわち、無効でない）ものが存在するか否かを判定する。存在する場合、処理をステップＳ１７９に進める。存在しない場合、処理をステップＳ１７４に進める。
【０２６８】
［ステップＳ１７４］セッション制御部４４０は、ＤＢクラスタ１０に対してセッション管理テーブル４１２に設定された無効なセッションの破棄を指示する無効セッション破棄要求を生成し、ＤＢ通信部４６０に出力する。ＤＢ通信部４６０は、無効セッション破棄要求をＤＢクラスタ１０に送信する。
【０２６９】
［ステップＳ１７５］ＤＢ通信部４６０は、ＤＢクラスタ１０からステップＳ１７４で指示したセッションを破棄した旨を示す無効セッション破棄応答を受信する。ＤＢ通信部４６０は、破棄応答をセッション制御部４４０に出力する。
【０２７０】
［ステップＳ１７６］セッション制御部４４０は、新たなセッションの開設をＤＢクラスタ１０に要求するためのセッション開設要求を生成する。セッション制御部４４０は、版数記憶部４７０に記憶されたサーバ版数テーブル４７１を参照してサーバ版数を取得し、取得したサーバ版数をセッション開設要求に含める。セッション制御部４４０は、取得したセッション開設要求をＤＢ通信部４６０に出力する。ＤＢ通信部４６０は、生成したセッション開設要求をＤＢクラスタ１０に送信する。
【０２７１】
［ステップＳ１７７］ＤＢサーバ１００は、ＡＰサーバ４００からセッション開設要求を受信すると、セッション開設処理を実行する。そして、ＤＢサーバ１００は、セッション開設処理を実行した結果、新規に割り当てたセッション番号等を示す新規セッション情報を生成してＡＰサーバ４００に送信する。
【０２７２】
［ステップＳ１７８］ＤＢ通信部４６０は、ＤＢクラスタ１０から新たに割り当てられたセッションを示す新規セッション情報とＤＢクラスタ１０のクラスタ版数とを受信する。ＤＢ通信部４６０は、受信した新規セッション情報とクラスタ版数とをセッション制御部４４０に出力する。セッション制御部４４０は、セッション管理テーブル４１２に新規セッション情報（例えば、セッション番号）を設定する。また、セッション制御部４４０は、新規セッションと共に受信したクラスタ版数を新規セッションに対応するセッション取得時版数として設定する。セッション管理テーブル４１２に設定された新規セッションは未割当セッションとなる。また、新規セッションは有効なセッションとなる。
【０２７３】
［ステップＳ１７９］セッション制御部４４０は、セッション管理テーブル４１２を参照して、ＤＢリクエストの生成元となったＡＰリクエストの送信元端末装置の識別情報（要求元識別情報）を有効かつ未割当のセッションに割り当てる。例えば、セッション管理テーブル４１２に含まれる有効かつ未割当のセッションのうち、エントリＩＤが最も小さいものを優先して割り当てる。
【０２７４】
このように、ＡＰサーバ４００は第２の実施の形態の処理に加えて、セッション開設要求にＡＰサーバ４００のサーバ版数を含める。ＤＢサーバ１００は、そのサーバ版数に基づいてセッション開設処理を実行することができる。
【０２７５】
なお、ＡＰサーバ４００は、セッション開設要求とサーバ版数とを別個に送信してもよい。例えば、ＤＢ通信部４６０がセッション開設要求をＤＢクラスタ１０に送信する際に、版数送受信部４９０がサーバ版数をＤＢクラスタ１０に送信することとしてもよい。
【０２７６】
次に、図３３のステップＳ１７７に示したＤＢサーバ１００のセッション開設処理を詳細に説明する。
図３４は、第３の実施の形態のセッション開設処理を示すフローチャートである。以下、図３４に示す処理をステップ番号に沿って説明する。
【０２７７】
［ステップＳ１８１］ＡＰ通信部１６０は、セッション開設要求を受信する。ＡＰ通信部１６０は、受信したセッション開設要求をセッション制御部４４０に出力する。
［ステップＳ１８２］セッション制御部４４０は、セッション開設要求に含まれるサーバ版数に基づいて、セッション解放処理を実行する。セッション解放処理は、図３０に示したステップＳ１４２以降の手順と同様である。ただし、サーバ版数はセッション開設要求に含まれる。このため、セッション制御部４４０は、ＡＰ通信部１６０から取得したセッション開設要求を参照して、サーバ版数を取得する。
【０２７８】
［ステップＳ１８３］セッション制御部４４０は、ＡＰサーバ４００に対して新規セッションを割り当てる。
［ステップＳ１８４］セッション制御部４４０は、版数記憶部１１０に記憶されたクラスタ版数テーブル１１１を参照してクラスタ版数を取得する。
【０２７９】
［ステップＳ１８５］セッション制御部４４０は、クラスタ版数および新規セッションの割り当て内容を示す新規セッション情報を含むセッション開設応答を生成する。セッション制御部４４０は、生成したセッション開設応答をＡＰ通信部１６０に出力する。
【０２８０】
［ステップＳ１８６］ＡＰ通信部１６０は、セッション制御部４４０から取得したセッション開設応答をＡＰサーバ４００に送信する。
このようにして、ＤＢサーバ１００はＡＰサーバ４００に対して新規セッションの開設を行う。その際、ＡＰサーバ４００から受信したサーバ版数に基づいて、セッション解放処理を実行することができる。
【０２８１】
なお、ステップＳ１８５において、ＤＢサーバ１００はクラスタ版数をセッション開設応答に含めることとしたが、セッション開設応答とクラスタ版数とを別個に送信してもよい。例えば、ＡＰ通信部１６０がセッション開設応答をＡＰサーバ４００に送信する際に、版数送受信部１９０がクラスタ版数をＡＰサーバ４００に送信することとしてもよい。
【０２８２】
図３５は、第３の実施の形態のＤＢレスポンス送信処理を示すフローチャートである。以下、図３５に示す処理をステップ番号に沿って説明する。
［ステップＳ１９１］ＡＰ通信部１６０は、ＡＰサーバ４００からＤＢリクエストを受信する。ＡＰ通信部１６０は、受信したＤＢリクエストに含まれるサーバ版数をセッション制御部４４０に出力する。また、ＡＰ通信部１６０は、ＤＢリクエストをＤＢ処理部１２０に出力する。
【０２８３】
［ステップＳ１９２］セッション制御部４４０は、サーバ版数に基づいて、セッション解放処理を実行する。セッション解放処理は、図３０に示したステップＳ１４２以降の手順と同様である。
【０２８４】
［ステップＳ１９３］ＤＢ処理部１２０は、セッション情報記憶部１７０に記憶されたセッション管理テーブル１７２を参照して、ＤＢリクエストに含まれる指定セッションは適正であるか否かを判定する。適正である場合、処理をステップＳ１９４に進める。適正でない場合、処理をステップＳ１９８に進める。
【０２８５】
［ステップＳ１９４］ＤＢ処理部１２０は、ＤＢリクエストに応じたＤＢ処理を実行する。
［ステップＳ１９５］ＤＢ処理部１２０は、版数記憶部１１０を参照してクラスタ版数を取得する。
【０２８６】
［ステップＳ１９６］ＤＢ処理部１２０は、ＤＢ処理の実行結果に基づいて、クラスタ版数を含むＤＢレスポンスを生成する。
［ステップＳ１９７］ＤＢ処理部１２０は、生成したＤＢレスポンスをＡＰ通信部１６０に出力する。ＡＰ通信部１６０は、取得したＤＢレスポンスをＡＰサーバ４００に送信する。なお、このＤＢレスポンスは正常にＤＢ処理がなされた際の応答であるので、正常応答である。
【０２８７】
［ステップＳ１９８］ＤＢ処理部１２０は、版数記憶部１１０を参照してクラスタ版数を取得する。ここで、版数記憶部１１０に記憶されたクラスタ版数が所定の初期値（例えば、“−１”）を示している場合は、サービス監視部１４０は新たなクラスタ版数を版数記憶部１１０に設定する。この場合、ＤＢ処理部１２０は、サービス監視部１４０が設定したクラスタ版数を取得する。
【０２８８】
［ステップＳ１９９］ＤＢ処理部１２０は、指定セッションが適正でない旨を示すセッション無効通知を生成する。ＤＢ処理部１２０は、セッション無効通知にクラスタ版数を含める。
【０２８９】
［ステップＳ２００］ＤＢ処理部１２０は、セッション無効通知をＡＰ通信部１６０に出力する。ＡＰ通信部１６０は、セッション無効通知およびクラスタ版数をＡＰサーバ４００に送信する。このレスポンスは、正常にＤＢ処理がなされない場合の応答であるので、正常応答ではない。この場合、ＡＰサーバ４００において図３１のステップＳ１５４で正常応答と判定されない。
【０２９０】
このように、ＤＢサーバ１００は第２の実施の形態のＤＢレスポンス送信処理の手順に加えて、ＡＰサーバ４００から受信したサーバ版数に基づくセッション解放処理（ステップＳ１９２）を実行する。
【０２９１】
これにより、ＤＢサーバ１００はＡＰサーバ４００との通信のためにプールしていたセッションのうち、利用される可能性のないものの再利用を可能とする。
なお、ステップＳ１９６〜Ｓ２００では、クラスタ版数を各種レスポンスに含めて生成し、送信するものとしたが、これらを別個にＡＰサーバ４００に送信してもよい。例えば、ＡＰ通信部１６０がＡＰサーバ４００に各種レスポンスを送信する際に、版数送受信部１９０がＡＰサーバ４００にクラスタ版数を送信することとしてもよい。
【０２９２】
次に、業務処理システムにおける処理の流れの具体例を説明する。なお、以下の例でもＤＢクラスタ１０およびＡＰサーバ４００との間の処理のみを説明するが、ＤＢクラスタ１０とＡＰサーバ５００，６００およびＤＢクラスタ２０，３０とＡＰサーバ４００，５００，６００との間の処理に関しても同様である。
【０２９３】
以下の各図におけるステップの直前では、ＤＢクラスタ１０につきＤＢサーバ１００が運用系、ＤＢサーバ１００ａが待機系の状態であるとする。
図３６は、第３の実施の形態のセッション解放処理を示す第１のシーケンス図である。以下、図３６に示す処理をステップ番号に沿って説明する。
【０２９４】
［ステップＳＴ３１］ＡＰサーバ４００は、ＡＰサービスの停止を開始する。
［ステップＳＴ３２］ＡＰサーバ４００は、サーバ版数を更新する。ＡＰサーバ４００は、ＤＢクラスタ１０へＡＰサービス停止開始通知およびサーバ版数を送信する。ＤＢサーバ１００は、ＡＰサーバ４００からＡＰサービス停止開始通知およびサーバ版数を受信する。
【０２９５】
［ステップＳＴ３３］ＤＢサーバ１００は、セッション解放処理を実行する。ＤＢサーバ１００は、ＡＰサーバ４００を“非運用中”とする。
［ステップＳＴ３４］ＡＰサーバ４００は、ＡＰサービスの起動を開始する。
【０２９６】
［ステップＳＴ３５］ＡＰサーバ４００は、ＡＰサービスの起動を完了する。
［ステップＳＴ３６］ＡＰサーバ４００は、サーバ版数を更新する。ＡＰサーバ４００は、ＤＢクラスタ１０へＡＰサービス起動完了通知およびサーバ版数を送信する。ＤＢサーバ１００は、ＡＰサーバ４００からＡＰサービス起動完了通知およびサーバ版数を受信する。
【０２９７】
［ステップＳＴ３７］ＤＢサーバ１００は、セッション解放処理を実行する。ＤＢサーバ１００は、ＡＰサーバ４００を“運用中”とする。
［ステップＳＴ３８］ＤＢサーバ１００は、ＡＰサーバ４００にクラスタ版数を送信する。ＡＰサーバ４００は、ＤＢサーバ１００からクラスタ版数を受信する。
【０２９８】
このように、ＡＰサーバ４００はＡＰサービスの停止開始時および起動完了時にサーバ版数を更新してＤＢクラスタ１０，２０，３０に送信する。そして、ＤＢクラスタ１０，２０，３０は、更新されたサーバ版数を受信した場合、ＡＰサーバ４００に割り当てていたセッションを解放する。
【０２９９】
このため、ＤＢクラスタ側の現用系のＤＢサーバ（例えば、ＤＢサーバ１００）は、ＡＰサーバ４００のＡＰサービス停止によって、ＡＰサーバ４００に利用されることがなくなったセッションを確実に解放することができる。解放されたセッションは、何れのＡＰサーバおよび処理の要求先スレッドにも割り当てられていない未割当の状態となる。したがって、ＤＢクラスタ１０，２０，３０はＡＰサーバ４００への無駄なセッションの割り当てを行うことがない。例えば、稼働中のＡＰサーバ５００，６００に対して、より多くのセッションを割り当てることも可能となる。すなわち、セッションを効率的に利用することができる。
【０３００】
また、ＤＢクラスタ１０，２０，３０は、ＡＰサーバ４００からＡＰサービス起動完了通知を受信すると、ＡＰサーバ４００にクラスタ版数を送信する。ＡＰサーバ４００はＤＢクラスタ１０，２０，３０からクラスタ版数を受信することで、それらのＤＢクラスタが利用可能であると検知することができる。例えば、クラスタ版数の受信元のＤＢクラスタを“運用中”として管理できる。一方、クラスタ版数を受信できなかったＤＢクラスタを“非運用中”として管理できる。
【０３０１】
更に、ＡＰサーバ４００はＡＰサービスの停止開始時だけでなく起動完了時にもサーバ版数を送信する。このため、ＡＰサーバ４００で障害等により停止開始時にサーバ版数の送信ができなかった場合にも、ＤＢクラスタ１０，２０，３０に対して確実にセッションの解放を促すことができる。次に、そのような場合を例示する。
【０３０２】
図３７は、第３の実施の形態のセッション解放処理を示す第２のシーケンス図である。以下、図３７に示す処理をステップ番号に沿って説明する。
［ステップＳＴ４１］ＡＰサーバ４００は、障害によりＡＰサービスが利用不可となる。このとき、ネットワークが利用できずにサーバ版数の送信が行えないものとする。
【０３０３】
［ステップＳＴ４２］ＡＰサーバ４００は、障害の復旧によりＡＰサービスの起動を開始する。
［ステップＳＴ４３］ＡＰサーバ４００は、ＡＰサービスの起動を完了する。
【０３０４】
［ステップＳＴ４４］ＡＰサーバ４００は、クラスタ版数を更新する。ＡＰサーバ４００は、ＤＢクラスタ１０へＡＰサービス起動完了通知およびサーバ版数を送信する。ＤＢサーバ１００は、ＡＰサーバ４００からＡＰサービス起動完了通知およびサーバ版数を受信する。
【０３０５】
［ステップＳＴ４５］ＤＢサーバ１００は、セッション解放処理を実行する。
［ステップＳＴ４６］ＤＢサーバ１００は、ＡＰサーバ４００にクラスタ版数を送信する。ＡＰサーバ４００は、ＤＢサーバ１００からクラスタ版数を受信する。
【０３０６】
このように、ＡＰサーバ４００は、障害によってＡＰサービス停止時のサーバ版数をＤＢクラスタ１０，２０，３０に送信できなかった場合にも、ＡＰサービス起動完了時にＤＢクラスタ１０，２０，３０にサーバ版数を送信する。このため、ＤＢクラスタ１０，２０，３０に対して確実にセッションの解放を促すことができる。
【０３０７】
第３の実施の形態の業務処理システムでは、ＤＢクラスタ１０，２０，３０側でもＡＰサーバ４００，５００，６００のサーバ版数を管理することとした。
これにより、第２の実施の形態と同一の効果に加えて、ＤＢクラスタ１０，２０，３０側でもＡＰサーバ４００，５００，６００の状態に応じてセッションの解放を適切に行うことができる。その結果、例えば空いたセッションを別のＡＰサーバに割り当てることができる。また、例えば、該当のセッションに割り当てていたメモリ等の資源を他の業務処理に利用することもできる。
【０３０８】
すなわち、ＤＢクラスタ１０，２０，３０の資源を効率的に利用することができるようになる。
なお、第２，３の実施の形態ではクラスタ版数およびサーバ版数としてタイムスタンプを用いることとしたがこれに限らない。
【０３０９】
例えば、クラスタ切替時やサービスの起動・停止に伴って所定の数値（例えば、１）を加算するよう管理された数値を版数としてもよい。ただし、これをクラスタ版数とする場合には、現用系と待機系とのＤＢサーバでクラスタ版数の同期を行う。これにより、ＡＰサーバ側でＤＢクラスタ単位に一貫したクラスタ版数の管理を行うことができる。
【０３１０】
以上、本発明の情報処理システム、情報処理装置、通信制御プログラムおよび通信制御方法を図示の実施の形態に基づいて説明したが、これらに限定されるものではなく、各部の構成は同様の機能を有する任意の構成のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。更に、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。
【符号の説明】
【０３１１】
１、２  情報処理装置
１ａ  接続情報記憶部
１ｂ  サービス提供部
１ｃ  監視部
１ｄ  送信部
２ａ  接続情報記憶部
２ｂ  サービス提供部
２ｃ  制御部
【図１】
2011159014.tif 000003
【図２】
2011159014.tif 000004
【図３】
2011159014.tif 000005
【図４】
2011159014.tif 000006
【図５】
2011159014.tif 000007
【図６】
2011159014.tif 000008
【図７】
2011159014.tif 000009
【図８】
2011159014.tif 000010
【図９】
2011159014.tif 000011
【図１０】
2011159014.tif 000012
【図１１】
2011159014.tif 000013
【図１２】
2011159014.tif 000014
【図１３】
2011159014.tif 000015
【図１４】
2011159014.tif 000016
【図１５】
2011159014.tif 000017
【図１６】
2011159014.tif 000018
【図１７】
2011159014.tif 000019
【図１８】
2011159014.tif 000020
【図１９】
2011159014.tif 000021
【図２０】
2011159014.tif 000022
【図２１】
2011159014.tif 000023
【図２２】
2011159014.tif 000024
【図２３】
2011159014.tif 000025
【図２４】
2011159014.tif 000026
【図２５】
2011159014.tif 000027
【図２６】
2011159014.tif 000028
【図２７】
2011159014.tif 000029
【図２８】
2011159014.tif 000030
【図２９】
2011159014.tif 000031
【図３０】
2011159014.tif 000032
【図３１】
2011159014.tif 000033
【図３２】
2011159014.tif 000034
【図３３】
2011159014.tif 000035
【図３４】
2011159014.tif 000036
【図３５】
2011159014.tif 000037
【図３６】
2011159014.tif 000038
【図３７】
2011159014.tif 000039