JP4882537B2

JP4882537B2 - タイマ連携によるリクエスト制御方法

Info

Publication number: JP4882537B2
Application number: JP2006169510A
Authority: JP
Inventors: 健造坂本; 琢也小木曽; 貴之浜田
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2006-06-20
Filing date: 2006-06-20
Publication date: 2012-02-22
Anticipated expiration: 2026-06-20
Also published as: JP2008003645A

Description

本発明は、クライアントから送信されるリクエスト（情報）に応じた処理を行うサーバ、これらのシステム（いわゆるクライアントサーバシステム）およびこれらを用いた制御方法に関する。より詳細には、いわゆるWebサーバと所定の機能を実行する機能サーバとを連携し、Webサーバで受付けられたリクエストに対する制御を実行する技術に関する。その中でも特に、リクエストに対するレスポンス（処理）に対する応答を、障害の発生などのために、所定の条件（一定時間内等）でできないことを検知した場合の通知に関する。なお、機能サーバとしては、いわゆるＪ２ＥＥサーバが含まれる（Ｊ２ＥＥはサンマイクロシステムズ社の商標）。

従来、クライアントサーバシステムにおいて、クライアントのリクエストに基づいた処理を実行中のサーバ内で発生した障害を検知するものとして、特許文献１がある。

特許文献１においては、クライアントサーバシステムにおいて、レスポンスを低下させることなく、複数のクライアントからのリクエストを処理することを可能とすることを目的としている。特許文献１においては、この目的を達成するために以下の構成を取っている。サービススレッド２３ａは、クライアント２１ａからのリクエスト２８を受信すると、要求された処理のタイムアウト時間と自分のスレッドＩＤをタイムアウト表２５に書込む。そして、リクエスト２８の処理を終了すると、タイムアウト表２５内のタイムアウト時間及びスレッドＩＤを消去する。監視スレッド２４は、定期的にタイムアウト表２５からタイムアウト時間を読み出して、現在の時刻と比較することにより、設定されたタイムアウト時間までに処理を終了していないサービススレッドを検出する。タイムアウトしたサービススレッドを発見した場合には、当該サービススレッドを強制的に終了させて、クライアント２１にエラーを通知する。

特開平8-263325号公報

しかしながら、特許文献１においては、従来はそもそもWebサーバと機能サーバが連携してリクエストを受付け、応答することは記載されていなかった。このことにも伴い、Webサーバと機能サーバ（Webコンテナ）間のタイマに関する連携基盤が確立されておらず、キューイングの時間も含めたリアルタイムで強制力のあるタイマ制御ができていなかった。そのため、Webサーバ側でタイムアウトしたにも関わらずWebコンテナ側で処理が仕掛かってしまい正常終了する、という事象が処理遅延発生時には多く見られた。この事象が発生すると、具体的には、（１）Webサーバでタイムアウトが発生した場合、クライアントではサーバ側の処理が正常終了したかどうかを把握する術がないため、クライアントは再度サーバにアクセスして処理結果を確認する必要が出てきてしまう。（２）クライアントが処理結果を確認するために再度サーバにアクセスした際に、サーバ側で仕掛中の処理が完了していない可能性があり、その処理が完了するまでの間クライアントは処理の結果を確認することができない。
が問題として挙げられる。

WebサーバとWebコンテナがタイマに関してリアルタイムな連携を行う基盤を整える。その処理内容は、Webサーバ側でタイムアウトを検知した場合、速やかにその旨をWebコンテナ側に通知し、リクエストの破棄を行い、処理に失敗した旨をWebサーバ経由でクライアントに通知する。すなわち、webサーバとWebコンテナでのタイムアウトについての役割（処理）分担にその特徴がある。

そして、Ｗｅｂサーバからタイムアウトを通知し、これをＷｅｂコンテナが受信した際の、当該Ｗｅｂコンテナでの該当リクエストに対する処理状況に応じて、Ｗｅｂコンテナ（もしくはＷｅｂサーバ）の対応処理を変更することも本発明に含まれる。例えば、該当リクエストのキューイング中もしくは業務処理中に、タイムアウト（を超過したことを示す情報）を受信した場合、リクエストの破棄処理（無効化処理）を行い、Ｗｅｂサーバ経由で破棄されたことを示す情報をクライアントに送信する。この際、業務処理中に受信した場合は、当該業務処理のトランザクションをロールバックしてからリクエストを破棄してもよい。なお、破棄されたことを示す情報は、ｗｅｂコンテナからクライアント端末に直接送信してもよい。

また、ここで、該当リクエストのキューイング中および業務処理中のいずれでもない場合に通知を受信した場合には、該当リクエストが正常終了した旨の通知を出力する。この通知も、ｗｅｂサーバを経由してクライアント端末に送信してもよい（これには、ｗｅｂサーバに送信し、ｗｅｂサーバがクライアント端末にその通知の形式などを変更して送信することも含み、破棄を示す通知の場合も同じ）し、直接クライアント端末に送信してもよい。

これによって、（１）の課題については、Webサーバでタイムアウトを検知した場合はWebコンテナ側でリクエストを破棄するため、処理結果が不明ではなく失敗している、という確実な情報をクライアントに返すことができ、状況は改善される。また、（２）の課題については、WebサーバとWebコンテナでリクエストのステータスについて同期が取れているため、クライアントが処理の失敗を認識して再度リクエストを送信した場合においても、サーバ側で処理が仕掛中のために待たされるような事象はなくなるため、状況は改善される。

本発明には、以下の態様も含まれる。なお、ここでは、リクエスト制御方法として表現されているが、各構成要件（クライアント端末、ｗｅｂサーバ、機能サーバ）を含むシステムおよびこれら各構成要件も本発明に含まれる。

クライアント端末とｗｅｂサーバと機能サーバが互いに接続されたシステムを用いたタイマ連携によるリクエスト制御方法において、前記クライアント端末から前記ｗｅｂサーバに対して、処理要求を含むリクエスト情報を送信し、前記ｗｅｂサーバが、前記リクエスト情報を受信し、受信されたリクエスト情報を前記機能サーバに送信し、前記機能サーバが、送信された前記リクエスト情報に対応する情報処理を実行し、前記ｗｅｂサーバが、前記リクエスト情報に対応する前記機能サーバの処理応答について、予め定められた時間外になっても前記処理応答がなされていないことを検知し、検知された内容を前記機能サーバに送信し、前記機能サーバは、前記情報処理の進捗状況が所定の条件を満たしているか否かを判定し、満たしている場合には前記リクエスト情報を無効化し、当該無効化を実行した旨を示す情報を前記クライアント端末に送信することを特徴とするタイマ連携によるリクエスト制御方法。また、このタイマ連携によるリクエスト制御方法において、前記機能サーバは、前記リクエスト情報のキューイング中もしくは対応する情報処理中に、前記検知された内容を受信した場合、前記所定の条件を満たすと判定することを特徴とするタイマ連携によるリクエスト制御方法。

また、このタイマ連携によるリクエスト制御方法において、前記機能サーバは、前記情報処理中に、前記検知された内容を受信した場合、当該情報処理のトランザクションをロールバックしてから前記リクエスト情報に対する無効化処理を実行することを特徴とするタイマ連携によるリクエスト制御方法。また、これらのタイマ連携によるリクエスト制御方法において、前記機能サーバは、前記リクエスト情報のキューイング中および対応する情報処理中のいずれでもない場合には、該当リクエストが正常終了した旨の通知を前記クライアント端末に送信することを特徴とするタイマ連携によるリクエスト制御方法。

WebサーバとWebコンテナのタイマ連携によって、従来技術では不可能であったキューイング中のリクエストの破棄が可能となる。これによって、従来遅延発生時に頻発していた「Webサーバがタイムアウトをクライアント端末に返すが、サーバ側で処理が仕掛かって正常に完了している」という不整合の発生確率を低減することが可能となる。

以下、本発明の実施の形態を詳細に説明する。

図１は、本発明をオンラインシステムの一般的な端末取引に適用した場合の処理手順の実施の形態を示すフローチャートであり、図２は、本発明に関わるサーバ装置の概要を示したブロック図である。

まず、図２のブロック図に基づいて全体の構成を示す。
クライアント端末10は、一般のエンドユーザが所有する携帯電話端末やPC端末を表している。クライアント端末が処理の起点となって、様々な処理の要求（リクエスト）をサーバに対して送信することが、最初のアクションとなる。

Webサーバ12は、クライアント端末10から受信したリクエストについて、（１）（既存）リクエストのURLより該当するWebコンテナ14上のアプリケーションに対して振分けを行う、（２）（既存）リクエストをリクエスト管理テーブル20に登録し、個々のリクエスト単位でタイマ監視を行う、（３）（新規）タイマ監視で閾値を超過したリクエストについてはWebコンテナ14に対してリクエストの破棄を要求するの役割を持つ。上記（１）（２）は既存のWebサーバが有する機能であり、（３）が本明細書にて提案するWebサーバの新機能に該当する。

Webコンテナ14では、Webサーバより振り分けられたリクエストを受信して、実際の業務処理を行う。Webサーバとのタイマ値の連携により、従来機能ではなし得なかった「Webサーバ側でのタイムアウト時のWebコンテナにおけるリクエストの破棄」が実現可能となる。

なお、上述した各装置は、いわゆるコンピュータであり、それぞれプログラムや情報を格納する記憶装置、メモリ、制御装置（ＣＰＵ）を有し、メモリに展開されたプログラムに従って制御装置が処理を実行する。

次に、図１のフローチャートに基づいて、図１、図２及び図３の各部の動作（すなわち、上述した処理の内容）を説明する。
図１において、クライアント端末10はリクエストをサーバに対して送信する（ステップ100）。すなわち、要求する処理内容を特定する情報を含むリクエストを送信する。

サーバ側では、まずWebサーバ12がこのリクエストを受信する（ステップ102）。次に、Webサーバ１２は、リクエスト管理テーブル20に受信したリクエストに関する情報（クライアントにユニークな情報（IPアドレス、端末機種名など）22、クライアントが要求したURL24、リクエストのタイマ監視開始時刻26及びリクエストのタイマ監視の閾値28）を登録する。そして、リクエストごとに個別にタイマ監視を開始する（ステップ104）。すなわち、ここで内蔵したタイマに起動をかけ、リクエスト管理テーブルのユニークな情報と対応付けてタイマの値を検知する。そして、この値とテーブルに格納された閾値を比較して、閾値を超過していないか判断する。

そして、リクエストをWebコンテナ14へ送信する（ステップ106）。

また、Webサーバ12は、ステップ１０４で開始されたタイマの閾値を超過するかどうか継続的に監視する（ステップ108）。ここでは、リクエストに対する応答（処理）が実行されたことを示す情報を受信するまでステップ１０８を実行してもよい。また、応答（処理）が実行されたことを示す情報を受信した場合に閾値内であれば、ＮＯと判断してステップ１３６に進んでもよい。この処理内容は、ステップ１０４と同様の処理を行ってもよい。

閾値を超過したと判断した場合は、タイマの閾値を超えた旨をWebコンテナへ通知する（ステップ110）。タイマの閾値を超えることなくWebコンテナ側で処理が完了した場合（完了通知の受信などで判定）、処理が正常終了した旨及び処理結果をWebコンテナより受信して、クライアントに対して同情報を送信する（ステップ136）。

＜Webサーバの挙動＞
まずWebサーバがタイマの閾値を超えた旨をWebコンテナへ通知する（ステップ110）。この際、リクエストに対する破棄を要求する情報を、Webコンテナ１４に送信する。そしてWebコンテナ１４から応答が送信された場合、これを受信する。Webコンテナから「リクエストの破棄に成功した」旨の通知（情報）を受信した（ステップ134）後、その旨を示す情報を、クライアント端末にレスポンスとして送信する。具体的には、例えばクライアントからのリクエストが口座振込処理であった場合、「振込処理に失敗しました。再度やり直してください」等のメッセージを含む情報を送信する。

＜Webコンテナの挙動＞
WebコンテナはWebサーバからリクエストを受信した（ステップ112）後、実行スレッドの空きの有無を確認する（ステップ114）。

ここでスレッドに空きがあった場合、リクエストをスレッドに移行して業務処理（トランザクション）を開始する（ステップ120）。スレッドに空きがなかった場合はリクエストを実行待ちキュー（既存）にキューイングし（ステップ116）、スレッドに空きが出た時点でスレッドに移行する（ステップ120）。

キューイングされている間、Webコンテナは常にWebサーバからのタイムアウト検知の通知を受信できる状態を維持している（ステップ118）。タイムアウトの通知を受信した場合、即座にリクエストの破棄を行い（ステップ126）、リクエストが破棄された旨をWebサーバへ通知する（ステップ128）。タイムアウトの通知を受信しなかった場合は、スレッドの空きを待って空きが出た時点でスレッドに移行する（ステップ120）。

リクエストがスレッドに移行すると、Webコンテナはトランザクションを開始する（ステップ120）。トランザクションの仕掛中（トランザクションが開始した後終了するまでの間）についても、Webコンテナは常にWebサーバからのタイムアウト検知の通知を受信できる状態を維持している（ステップ122）。トランザクション仕掛中にタイムアウトの通知を受信した場合、まずトランザクションのロールバックを行い（ステップ124）、リクエストを破棄し（ステップ126）、リクエストの破棄に成功した旨をWebサーバへ通知する（ステップ128）。トランザクション仕掛中にタイムアウトの通知を受信しなかった場合、トランザクションをコミットし（ステップ130）、リクエストが正常終了した旨をWebサーバへ通知する（ステップ132）。

本発明の処理手順の実施の形態を示すフローチャートである。本発明を適用する前の既存技術の処理手順の形態を示すフローチャートである。本発明に関わるサーバ装置のブロック図である。

符号の説明

10 クライアント端末
12 Webサーバ
14 Webコンテナ
20 リクエスト管理テーブル

Claims

クライアント端末とｗｅｂサーバと機能サーバが互いに接続されたシステムを用いたタイマ連携によるリクエスト制御方法において、
前記クライアント端末から前記ｗｅｂサーバに対して、処理要求を含むリクエスト情報を送信し、
前記ｗｅｂサーバが、前記リクエスト情報を受信し、受信されたリクエスト情報を前記機能サーバに送信し、
前記機能サーバが、送信された前記リクエスト情報に対応する情報処理を実行し、
前記ｗｅｂサーバが、前記リクエスト情報に対応する前記機能サーバの処理応答について、予め定められた時間外になっても前記処理応答がなされていないことを検知し、検知された内容を前記機能サーバに送信し、
前記機能サーバは、前記検知された内容を受信した場合、前記情報処理の進捗状況が所定の条件を満たしているか否かを判定し、満たしている場合には前記リクエスト情報を無効化し、当該無効化を実行した旨を示す情報を前記クライアント端末に送信することを特徴とするタイマ連携によるリクエスト制御方法。
請求項１に記載のタイマ連携によるリクエスト制御方法において、
前記機能サーバは、前記リクエスト情報のキューイング中もしくは対応する情報処理中
に、前記検知された内容を受信した場合、前記所定の条件を満たすと判定することを特徴
とするタイマ連携によるリクエスト制御方法。
請求項２に記載のタイマ連携によるリクエスト制御方法において、
前記機能サーバは、前記情報処理中に、前記検知された内容を受信した場合、当該情報処理のトランザクションをロールバックしてから前記リクエスト情報に対する無効化処理を実行することを特徴とするタイマ連携によるリクエスト制御方法。
請求項２または３のいずれかに記載のタイマ連携によるリクエスト制御方法において、
前記機能サーバは、前記リクエスト情報のキューイング中および対応する情報処理中のいずれにおいても、前記検知された内容を受信しなかった場合には、該当リクエストが正常終了した旨の通知を前記クライアント端末に送信することを特徴とするタイマ連携によるリクエスト制御方法。