JP2013145606A

JP2013145606A - データ処理装置

Info

Publication number: JP2013145606A
Application number: JP2013095782A
Authority: JP
Inventors: Takashi Nakajima; 貴史中島; Yoshifumi Kimura; 宜史木村
Original assignee: Bank of Tokyo Mitsubishi UFJ Trust Co
Current assignee: MUFG Bank Ltd
Priority date: 2013-04-30
Filing date: 2013-04-30
Publication date: 2013-07-25
Anticipated expiration: 2028-08-07
Also published as: JP5604554B2

Abstract

【課題】更新対象データの更新を並列に行う際のデータの矛盾の発生を防止する。
【解決手段】更新対象データの更新に用いられる交信用データが入力され、入力された更新用データを保持する保持手段と、更新対象データを格納する複数の記憶手段と、１または複数のプロセスを制御する制御部であって、１または複数のプロセスは、保持手段から更新用データを取り出し複数の記憶手段のいずれかの記憶手段に格納されている更新対象データを、取り出した更新用データに基づいて更新する処理を繰り返し、制御部は、保持手段に保持されている更新用データの数を取得し、取得された数が第１の値よりも小さければ、１または複数のプロセスの中から選択を行い選択されたプロセスを停止させ、取得された数が第１の値よりも大きな第２の値より大きければ、新たにプロセスを起動させて前記処理を繰り返させる制御を行なうことを特徴とするデータ処理装置
【選択図】図６

Description

本発明はデータ処理装置及びプログラムに係り、特に、順次入力される更新用データに基づいて、記憶手段の格納領域に格納されている更新対象データを更新するデータ処理装置、及び、コンピュータを前記データ処理装置として機能させるためのデータ処理プログラムに関する。

金融機関のコンピュータ・システムのうち、各種金融取引の取引明細を記憶するデータベース(取引明細系ＤＢ)を更新・管理する取引明細管理システムでは、実行が指示された個々の金融取引を直ちに確定させるため、個々の金融取引を表す電文を受信する毎に、例として図７に示すように、受信した電文の内容を取引明細系ＤＢへ即時に反映する処理を行っている。また、取引明細系ＤＢへの即時反映よりは優先度が低いものの、金融機関全体としての資金繰りや決済の状況を把握したいというニーズがあり、このニーズを満たすため、上記の取引明細管理システムでは、資金繰りや決済の状況を表す情報を登録するための複数種の状況管理テーブル（図７の例では「ステータス別件数金額」、「資金繰推移状況」、「資金繰予定実績」及び「モニタリング情報」の各状況管理テーブル）を受信した電文の内容に応じて適宜更新すると共に、オペレータからの指示に従って上記各状況管理テーブルの内容をディスプレイに表示させる処理も行っている。

なお、状況管理テーブルの更新は、詳しくは図７にも示すように、電文を受信する毎に、受信した電文の内容に基づき何れかの状況管理テーブルを更新するための更新用データを生成し、生成した更新用データをキュー(待ち行列)の末尾に投入すると共に、キューの先頭から更新用データを取り出し、取り出した更新用データに対応する状況管理テーブルを、取り出した更新用データに従って更新することによって成される。また、実際の資金繰りや決済の状況の変化がディスプレイの表示に反映される迄の遅延時間が大きくなることは望ましくないので、取引明細管理システムでは、キューの先頭から更新用データを取り出して対応する状況管理テーブルを更新する処理を、複数のプロセス（テーブル更新プロセス）によって並列に行っている。

上記に関連して特許文献１には、トランザクションからのレコード更新要求に基づくデータファイルの更新に際し、要求されたデータファイルのレコードへの同時アクセスを排他制御し、要求されたデータファイルのレコードの更新を第１のバッファ上で実行すると共に、第１のバッファ上でのレコード更新の履歴をレコード単位で生成しておき、当該トランザクションの確定時には、生成しておいた当該トランザクションに対応するレコード単位の更新履歴をジャーナルファイルに記録し、ジャーナルファイルに記録した更新履歴に基づき第２のバッファを通じてブロック単位でデータファイルを更新する技術が開示されており、トランザクション間の排他制御をレコード単位で行うことにより、トランザクションの並列実効性の向上を実現している。

また、特許文献２には、処理データを一旦全てメモリ上に配置し、メモリ上でデータ更新処理を行うと共に、処理が全て完了、或いは或る程度まとまった単位の更新が完了した時点でディスクに保存することで、高速なトランザクション処理を実現する技術が開示されている。

特開平９−６２５５０号公報特開２００７−３１４６９１号公報

先に説明した取引明細管理システムのように、並列に動作する複数のプロセス（インスタンス、スレッド、或いはミドルともいう）が同一のテーブルやＤＢを更新する処理を非同期で各々行う構成では、異なるプロセスによる同一のテーブルやＤＢへのアクセスが競合し、データの矛盾等が生ずる可能性がある。このデータの矛盾に関しては、例えば特許文献１に記載の技術のように、或るプロセスがテーブル等を更新している間、他のプロセスによる同一テーブルの更新を禁止するロックをかける等の排他制御を行うことで回避できる。しかし、排他制御を行うとオーバヘッドが増大すると共に、アクセスの競合の発生時に一方のアクセスが完了する迄他方のアクセスが待たされることで、処理効率が低下するという問題がある。

一例として、図７の構成では、取引明細管理システムの受信電文数が数万件／分に達した場合、キューに数万件の更新用データが滞留し、更新用データをキューへ投入してから前記更新用データに基づいて状況管理テーブルが更新される迄に、数分程度もの時間が掛っていた。

これに対し、特許文献１に記載の技術は、排他制御を行う単位を小さくすることでアクセスの競合の発生頻度を低下させる技術であり、排他制御を行うことによるオーバヘッドは削減できず、アクセスの競合の発生頻度を０にすることもできないので、処理効率の大幅な向上は望めない。また、特許文献２に記載の技術は、或る程度まとまった単位の更新が完了した時点でディスクに保存するので、更新対象のテーブルやＤＢが実際に更新される迄に時間が掛ることになり、前述した取引明細管理システムのように、更新対象のテーブルやＤＢの早期更新が要求される場合には適していない。

本発明は上記事実を考慮して成されたもので、更新対象データの更新を並列に行う際のデータの矛盾等の発生防止と処理効率の向上を両立できるデータ処理装置及びデータ処理プログラムを得ることが目的である。

上記目的を達成するために第１の発明に係るデータ処理装置は、更新対象データの更新に用いられる更新用データが順に入力され、入力された更新用データを各々保持する保持手段と、ｍ個(ｍ≧２)設けられた格納領域に前記更新対象データを各々格納する記憶手段と、互いに並列に動作し、前記保持手段から前記更新用データを取り出し、前記記憶手段のｍ個の格納領域のうちの互いに異なる格納領域に格納されている前記更新対象データを、前記取り出した更新用データに基づいて更新する処理を繰り返すｎ個(ｎ≧２かつｎ≦ｍ)の処理手段と、を含んで構成されている。

第１の発明では、更新対象データの更新に用いられる更新用データが順に入力され、入力された更新用データが保持手段に各々保持される。また、記憶手段には更新対象データを格納する格納領域がｍ個(ｍ≧２)設けられており、更新対象データはｍ個の格納領域に各々格納されている。そして第１の発明は、互いに並列に動作するｎ個(ｎ≧２かつｎ≦ｍ)の処理手段を備えており、個々の処理手段は、保持手段から更新用データを取り出し、記憶手段のｍ個の格納領域のうちの互いに異なる格納領域に格納されている更新対象データを、取り出した更新用データに基づいて更新する処理を繰り返す。

このように、第１の発明では、互いに並列に動作するｎ個の処理手段が、互いに異なる格納領域に格納されている互いに異なる更新対象データを更新するので、個々の格納領域に
格納されている更新対象データが、各々単一の処理部によって更新されることになり、或る更新対象データが複数の処理手段によってほぼ同時に更新されることで、データの矛盾等が生ずることを防止できると共に、複数の処理手段が同一の更新対象データをほぼ同時に更新しようとしてアクセスの競合が発生することも防止できる。

また、更新対象データの出力は、第８の発明のように、記憶手段のｍ個の格納領域に格納されている更新対象データを各々読み出し、読み出したｍ個の更新対象データを単一のデータに統合して出力することで行うことができるが、この場合は更新対象データを読み出すのみで更新は行われないので、或る更新対象データに対し、処理手段による更新と上記の統合のための読み出しがほぼ同時に行われたとしても、更新したデータの矛盾は生じない。従って、第１の発明によれば、更新対象データの更新を並列に行う際のデータの矛盾等の発生防止と処理効率の向上を両立することができる。

なお、第１の発明において、個々の処理手段が、互いに異なる格納領域に格納されている更新対象データを更新するように構成することは、例えば個々の処理手段に対し、更新対象データの更新を行う格納領域を識別するための識別情報として、互いに異なる格納領域を指し示す識別情報を設定しておき、更新対象データの更新時には設定された識別情報を参照することで更新対象データの更新を行う格納領域を識別するように個々の処理手段を構成することで実現できるが、この方式は、例えば単位時間当りに入力される更新用データの数が大幅に変化した等の理由で、本発明に係るデータ処理装置の稼働中に処理手段の数を増減させる可能性がある場合には適当ではない。

これを考慮すると、第１の発明において、例えば第２の発明のように、変数ｘ及び処理手段の総数ｎを記憶する変数記憶手段を更に設け、処理手段を、保持手段から更新用データを取り出す度に、変数記憶手段から変数ｘの値及び総数ｎの値を読み出し、変数記憶手段に記憶されている変数ｘの値を更新する（例えば１だけインクリメントするか、１だけデクリメントする等）と共に、読み出した変数ｘの値を処理手段の総数ｎで除した剰余の値に基づいて、記憶手段のｍ個の格納領域のうち更新対象データの更新を行う格納領域を決定するように構成することが好ましい。第２の発明では、個々の処理手段において、保持手段から更新用データを取り出す度に処理手段の総数ｎの値が確認され、確認された総数ｎの値を用いて更新対象データの更新を行う格納領域を決定するので、データ処理装置の稼働中に処理手段の数を増減する場合に、動作中の処理手段の処理を一旦停止させる必要が無くなる。

なお、第２の発明では、個々の処理手段が変数記憶手段に記憶されている変数ｘの値の読み出し及び更新を各々行うので、変数ｘの値の読み出し及び更新自体がごく短時間で完了する簡単な処理であるために極めて稀なケースではあるものの、複数の処理手段によって変数記憶手段に記憶されている変数ｘの値が同時に読み出されることで、複数の処理手段によって読み出される変数ｘの値が同一となり、複数の処理手段によって同一の更新対象データがほぼ同時に更新され、更新対象データに矛盾等が生ずる恐れがある。この問題は、変数ｘのアクセスに対して排他制御を行うか、個々の処理手段による個々の格納領域のアクセス（更新対象データの更新）に対して排他制御を行うことで解決することができる。この場合、排他制御を行うことでオーバヘッドは増大するものの、先の説明からも明らかなようにアクセスの競合が発生する頻度は非常に低いので、排他制御を行うことによる処理効率の低下を必要最小限に抑制することができる。

また、第２の発明において、本発明に係るデータ処理装置の稼働中に処理手段の数を増減させることは人手で行ってもよいが、例えば第３の発明のように、処理手段の数を増加又は減少させる必要があるか否かを判断し、判断結果に応じて処理手段の数を増加又は減少させると共に、変数記憶手段に記憶されている総数ｎの値を更新する制御手段を設けても
よい。

また、第３の発明において、制御手段による、処理手段の数を増加又は減少させる必要があるか否かの判断は、例えば第４の発明のように、保持手段に保持されている更新用データの数、又は、入力された更新用データが保持手段に保持されてから、更新用データの読み出し及び読み出した更新用データに基づく更新対象データの更新が完了する迄の処理時間に基づいて行うことができる。これにより、例えば単位時間当りに入力される更新用データの数が大幅に変化した等の場合に、当該変化に応じて処理手段の数が自動的に増加又は減少されることになり、動作している処理手段の数を、単位時間当りに入力される更新用データの数やその変化等に応じて最適化することができる。

また、第３の発明において、コンピュータを処理手段として機能させるためのプログラムを実行する所定のプロセスが、コンピュータによって実行されることで個々の処理手段が実現される場合、制御手段は、例えば第５の発明のように、所定のプロセスを追加生成させることで処理手段の数を増加させ、稼働中の所定のプロセスの稼働を停止させることで処理手段の数を減少させるように構成することができる。

また、第１〜第５の何れかの発明において、処理手段は、例えば第６の発明のように、記憶手段の複数の格納領域のうち自身が更新対象データの更新を行う格納領域をロックし、ロックした格納領域に格納されている更新対象データを更新した後に、格納領域のロックを解除する処理を行うように構成してもよい。特に第２の発明において、更新対象データに矛盾等が生ずる恐れを排除するためには、変数ｘのアクセスに対して排他制御を行うか、個々の処理手段による個々の格納領域のアクセス（更新対象データの更新）に対して排他制御を行う必要があるが、本願発明者は、格納領域のアクセスに対して排他制御を行った方が負荷の増大、処理効率の低下を抑制できることを確認しており、第６の発明は、特に第２の発明を実施する場合に有効である。

また、第１〜第６の何れかの発明において、記憶手段の数は１個に限られるものではなく、例えば第７の発明のように、記憶手段がｐ個設けられ、個々の記憶手段の格納領域には、ｐ種類の更新対象データのうちの互いに異なる更新対象データが格納されており、保持手段に入力される更新用データには、ｐ種類の更新対象データのうちの互いに異なる更新対象データに用いられるｐ種類の更新用が混在していてもよい。この場合、処理手段は、保持手段から更新用データを取り出し、ｐ個の記憶手段のうち取り出した更新用データの種類に対応する記憶手段を選択し、選択した記憶手段の何れかの格納領域に格納されている更新対象データを取り出した更新用データに基づいて更新するように構成することができる。

また、第１〜第７の何れかの発明において、例えば第８の発明のように、記憶手段のｍ個の格納領域に格納されている更新対象データを各々読み出し、読み出したｍ個の更新対象データを単一のデータに統合して出力する統合手段を更に設けることが好ましい。これにより、複数の処理手段が、記憶手段のｍ個の格納領域のうちの互いに異なる格納領域に格納されている更新対象データを、保持手段から取り出した更新用データに基づいて更新する処理を繰り返す構成（本発明の構成）において、単一の更新対象データに対してのみ更新を行い、単一の更新対象データを適宜出力する構成と同等の出力を得ることができる。

第９の発明に係るデータ処理プログラムは、更新対象データの更新に用いられる更新用データが順に入力され、入力された更新用データを各々保持する保持手段を備えると共に、ｍ個(ｍ≧２)設けられた格納領域に前記更新対象データを各々格納する記憶手段を備えるか、又は、前記記憶手段と接続されたコンピュータを、互いに並列に動作し、前記保持手段から前記更新用データを取り出し、前記記憶手段のｍ個の格納領域のうちの互いに異なる格納領域に格納されている前記更新対象データを、前記取り出した更新用データに基づいて更新する処理を繰り返すｎ個(ｎ≧２かつｎ≦ｍ)の処理手段として各々機能させる。

第９の発明に係るデータ処理プログラムは、上記の保持手段を備えると共に、上記の記憶手段を備えるか、又は、上記の記憶手段と接続されたコンピュータを、上記のｎ個の処理手段として機能させるためのプログラムであるので、コンピュータが第９の発明に係るデータ処理プログラムを実行することで、コンピュータが第１の発明のデータ処理装置として機能することになり、第１の発明と同様に、更新対象データの更新を並列に行う際のデータの矛盾等の発生防止と処理効率の向上を両立することができる。

第１０の発明に係るデータ処理プログラムは、更新対象データの更新に用いられる更新用データが順に入力され、入力された更新用データを各々保持する保持手段を備えると共に、ｍ個(ｍ≧２)設けられた格納領域に前記更新対象データを各々格納する記憶手段を備えるか、又は、前記記憶手段と接続されたコンピュータを、第１〜第８の何れかの発明のデータ処理装置を構成する各手段として機能させる。

第１０の発明のデータ処理プログラムは、上記コンピュータを、第１〜第８の何れかの発明のデータ処理装置を構成する各手段として機能させるプログラムであるので、コンピュータが第１０の発明に係るデータ処理プログラムを実行することで、コンピュータが第１〜８の何れかの発明のデータ処理装置として機能することになり、少なくとも、更新対象データの更新を並列に行う際のデータの矛盾等の発生防止と処理効率の向上を両立することができる。

以上説明したように本発明は、互いに並列に動作するｎ個(ｎ≧２かつｎ≦ｍ)の処理手段で、順に入力された更新用データを各々保持する保持手段から更新用データを取り出し、記憶手段のｍ個(ｍ≧２)の格納領域のうちの互いに異なる格納領域に格納されている更新対象データを、取り出した更新用データに基づいて更新する処理を繰り返すようにしたので、更新対象データの更新を並列に行う際のデータの矛盾等の発生防止と処理効率の向上を両立できる、という優れた効果を有する。

以下、図面を参照して本発明の実施形態の一例を詳細に説明する。図１には本実施形態に係るコンピュータ・システム１０が示されている。本実施形態に係るコンピュータ・システム１０は特定金融機関に設置されており、サーバ・コンピュータ１２と、特定金融機関内に構築されたコンピュータ・ネットワーク１４を含んで構成されている。コンピュータ・ネットワーク１４は、複数台のコンピュータ（例えば特定金融機関の各支店に各々設置されたブランチ・サーバ等）や複数台の端末（例えば営業店端末（特定金融機関の従業員が操作するための端末）やＡＴＭ（Automatic Teller Machine：現金自動預け払い機）等）が通信回線を介して互いに接続されて構成されている。

一方、サーバ・コンピュータ１２はＣＰＵ１２Ａ、メモリ１２Ｂ、記憶部１２Ｃ及びネットワーク・インタフェース(Ｉ／Ｆ)部１２Ｄを備え、ＣＲＴやＬＣＤ等から成るディスプレイ１８、キーボード２０、取引明細系ＤＢを記憶するストレージ２２が各々接続されている。なお、取引明細系ＤＢには各種金融取引の取引明細の情報が記憶される。図１ではストレージ２２を１台のみ示しているが、取引明細系ＤＢは複数台のストレージ２２に分けて記憶されていてもよい。サーバ・コンピュータ１２のネットワークＩ／Ｆ部１２Ｄは、前述のコンピュータ・ネットワーク１４と通信回線を介して接続されており、更に、日本銀行に設置されたコンピュータ・システム（日銀システム）２４とも通信回線を介して接続されている。サーバ・コンピュータ１２、ディスプレイ１８、キーボード２０及びストレージ２２は、コンピュータ・ネットワーク１４や日銀システム２４から電文を受信し、受信した電文に従って取引明細系ＤＢを更新・管理する取引明細管理システムとして機能する。

また、サーバ・コンピュータ１２の記憶部１２Ｃには、オペレーティング・システムのプログラム、電文受信プログラム、テーブル更新プログラム、データ統合出力プログラム、及び、稼働プロセス数管理プログラムが各々インストールされている。このうち、オペレーティングシステムのプログラムを除く各プログラムは、オペレータからの指示をトリガとして、特定金融機関全体としての資金繰りや決済の状況を表す情報をディスプレイ１８に表示させる機能を実現するためのプログラムであり、第９,１０の発明のデータ処理プログラムに対応している。サーバ・コンピュータ１２は第９の発明のコンピュータに対応しており、ＣＰＵ１２Ａによってこれらのプログラムが実行されることで本発明に係るデータ処理装置として機能する。

またサーバ・コンピュータ１２の記憶部１２Ｃには、ステータス別件数金額テーブル、資金繰推移状況テーブル、資金繰予定実績テーブル及びモニタリング情報テーブルから成る状況管理テーブル群が記憶されている。サーバ・コンピュータ１２（取引明細管理システム）は、特定金融機関全体としての資金繰りや決済の状況を表す情報として、複数種のモニタ項目の情報をディスプレイ１８に表示可能とされており、状況管理テーブル群の各テーブルには、個々のモニタ項目に対応する互いに異なる業務データが登録される。

より詳しくは、モニタ項目「ステータス別件数金額」に対応するステータス別件数金額テーブルには、「ステータス別件数金額」に対応する業務データとして、決済の状態（例えば「完了」や「処理中」等）毎の金融取引の件数、金額等のデータが登録され、モニタ項目「資金繰推移状況」に対応する資金繰推移状況テーブルには、「資金繰推移状況」に対応する業務データとして、特定金融機関全体としての資金繰の実績の推移及び今後の予定（見込み）を表すデータが登録され、モニタ項目「資金繰予定実績」に対応する資金繰予定実績テーブルには、「資金繰予定実績」に対応する業務データとして、要因毎の資金繰の予定・実績を表すデータが登録され、モニタ項目「モニタリング情報」に対応するモニタリング情報テーブルには、「モニタリング情報」に対応する業務データとして、特定金融機関全体としての資金繰の時間帯毎の実績を表すデータが登録される。なお、状況管理テーブル群の各テーブルに登録されている業務データは本発明に係る更新対象データに対応している。

次に本実施形態の作用を説明する。サーバ・コンピュータ１２では、電源が投入されサーバ・コンピュータ１２上でオペレーティング・システムが稼働を開始すると、初期設定のために稼働プロセス数管理プログラムが記憶部１２Ｃから読み出されてＣＰＵ１２Ａによって実行されることで、図５に示す稼働プロセス数管理処理が行われる。

この稼働プロセス数管理処理では、まずステップ６０において、稼働プロセス数管理処理の今回の起動要因が初期設定か否か判定する。この場合は判定が肯定されてステップ６２へ移行し、メモリ１２Ｂに予め設けられている変数ｘの記憶領域に変数ｘの初期値として１を設定する。次のステップ６４では、メモリ１２Ｂに予め設けられているテーブル更新プロセスの稼働数ｎの記憶領域に、テーブル更新プロセスの稼働数ｎの初期値を設定する。なお、テーブル更新プロセスの稼働数ｎの初期値は、例えばサーバ・コンピュータ１２の稼働開始直後の時間帯における取引明細管理システムの電文受信数等に応じて定めることができるが、これに代えて、サーバ・コンピュータ１２の稼働中における取引明細管理システムの電文受信数の最大値等に応じて定めてもよい。

次のステップ６６では、オペレーティング・システムに対し、記憶部１２Ｃに記憶されて
いるテーブル更新プログラムをＣＰＵ１２Ａによって実行するプロセス（テーブル更新プロセス）を、ステップ６４で設定した稼働数ｎと同数個生成するよう指示する。これにより、ｎ個のテーブル更新プロセスがオペレーティング・システムによって生成され、生成されたテーブル更新プロセスが稼働を開始する。なお、テーブル更新プロセスは、個々のプロセスに対応するテーブル更新プログラムがＣＰＵ１２Ａによって時分割で各々実行されることで互いに並列に動作する。次のステップ６８ではタイマをスタートさせ、稼働プロセス数管理処理を終了する。

また、サーバ・コンピュータ１２がコンピュータ・ネットワーク１４や日銀システム２４から電文を受信すると、電文受信プログラムが記憶部１２Ｃから読み出されてＣＰＵ１２Ａによって実行されることで、図２に示す電文受信処理が行われる。この電文受信処理では、まずステップ３０において、コンピュータ・ネットワーク１４又は日銀システム２４から受信した単一の電文の内容に基づき、ストレージ２２に記憶されている取引明細系ＤＢを更新する。次のステップ３２では、受信した単一の電文の内容に基づき、各モニタ項目に対応する更新用データ（状況管理テーブル群の各テーブルに登録されている個々の業務データを更新するための更新用データ）を各々生成する。そしてステップ３４では、ステップ３０で生成した各モニタ項目毎の更新用データを、メモリ１２Ｂ上に形成されたキュー（待ち行列）の末尾に投入し、電文受信処理を終了する。

上記の電文受信処理はサーバ・コンピュータ１２が電文を受信する毎に実行される。従って、取引明細系ＤＢを受信した電文の内容に応じて即時に更新される。また、サーバ・コンピュータ１２が電文を受信する毎に、例として図６に示すように、受信した単一の電文からモニタ項目「ステータス別件数金額」に対応する更新用データ、モニタ項目「資金繰推移状況」に対応する更新用データ、モニタ項目「資金繰予定実績」に対応する更新用データ、モニタ項目「モニタリング情報」に対応する更新用データが各々生成され、生成された更新用データがキューの末尾に投入されることになる。

なお、キューに繋がれた更新用データを記憶するメモリ１２Ｂは、メモリ１２Ｂ上にキューを形成して管理する処理と共に、本発明に係る保持手段に対応している。但し、保持手段はこの構成に限られるものではなく、ＦＩＦＯメモリや一般的なバッファ等を保持手段として用いることも可能である。

また、前述の稼働プロセス数管理処理からの指示によってオペレーティング・システムで生成されたｎ個のテーブル更新プロセスでは、記憶部１２Ｃに記憶されているテーブル更新プログラムがＣＰＵ１２Ａによって実行されることで、図３に示すテーブル更新処理を行っている。

このテーブル更新処理では、まずステップ４０において、キューに更新用データが保持されているか否か判定する。判定が否定された場合は一旦処理を終了し、次回のプログラム実行期間にステップ４０の判定が再度行われることで、上記判定が肯定される迄ステップ４０を繰り返す。前述した電文受信処理によってキューに更新用データが投入されると、ステップ４０の判定が肯定されてステップ４２へ移行し、キューの先頭に保持されている更新用データをキューから取り出す。ステップ４４ではメモリ１２Ｂ上の変数ｘの記憶領域から変数ｘを読み出し、次のステップ４６では、上記記憶領域に記憶されている変数ｘを１だけインクリメントする。またステップ４８では、メモリ１２Ｂ上の稼働数ｎの記憶領域からテーブル更新プロセスの稼働数ｎを読み出す。そしてステップ５０では、ステップ４４で読み出した変数ｘ及びステップ４８で読み出したテーブル更新プロセスの稼働数ｎを次の(１)式に代入して演算することで、更新対象の業務データが格納された格納領域ｉを決定する。
ｉ←ＭＯＤ(ｘ／ｎ)＋１ …(１)
なお、(１)式におけるＭＯＤ( )は、括弧内の演算における剰余を表す演算子である。

図６に示すステータス別件数金額テーブルを図７に示すステータス別件数金額テーブルと比較しても明らかなように、本実施形態では、状況管理テーブル群の各テーブルに、各テーブルに登録する業務データを格納可能な格納領域がｍ個（ｍ≧２）ずつ設けられており、単一のテーブル内の個々の格納領域には同一種の業務データが各々格納されている。このように、格納領域がｍ個設けられた単一のテーブルを記憶する記憶部１２Ｃは本発明に係る記憶手段に対応しており、状況管理テーブル群のｐ個（本実施形態ではｐ＝４）のテーブルを各々記憶する記憶部１２Ｃは第７の発明のｐ個の記憶手段にも対応している。なお、状況管理テーブル群の各テーブルを別々の記憶部に記憶させるようにしてもよい。各テーブル内の個々の格納領域には同一のテーブル内の個々の格納領域を識別するための通番（１〜ｍ）が付与されており、上記のステップ５０では(１)式の演算を行うことで、更新を行う業務データが格納された格納領域の通番ｉを決定している。

なお、単一のテーブル内の格納領域の数ｍの値は、テーブル更新プロセスの稼働数ｎの値以上であればよい（ｍ≧ｎ）が、後述するように、本実施形態ではサーバ・コンピュータ１２の稼働中にテーブル更新プロセスの稼働数ｎが増減される可能性がある一方、個々のテーブル内の格納領域の数ｍを増減させる処理は複雑であるので、テーブル更新プロセスの稼働数ｎに上限値ｎmaxを予め設定しておき、個々のテーブル内の格納領域の数ｍを上
限値ｎmaxに一致させておくことが望ましい。これにより、サーバ・コンピュータ１２の
稼働中に、テーブル更新プロセスの稼働数ｎの増減に拘わらず個々のテーブル内の格納領域の数ｍを変化させる必要が無くなり、処理が簡単になる。

ところで、個々のテーブル更新プロセスが先の(１)式に従って業務データの更新を行う格納領域を決定した場合、個々のテーブル更新プロセスによる業務データの更新が常に一定の格納領域に対して行われるとは限らないものの、個々のテーブル更新プロセスによって決定される業務データ更新対象の格納領域の通番ｉは、個々のテーブル更新プロセスによる変数ｘの読出順に相当する値となり、個々のテーブル更新プロセスは互いに異なる格納領域に格納されている業務データの更新を行うことになる。

但し、テーブル更新処理のステップ４４での変数ｘの読み出し及びステップ４６での変数ｘの更新(インクリメント)は、何れもごく短時間で完了する簡単な処理であるので、極めて稀なケースではあるものの、或るテーブル更新プロセスがステップ４４で変数ｘを読み出してからステップ４６で変数ｘの更新を行う迄の間に、別のテーブル更新プロセスによってステップ４４の変数ｘを読み出しが行われた場合、それぞれのテーブル更新プロセスが読み出した変数ｘの値が同一となり、(１)式によって決定した業務データ更新対象の格納領域の通番ｉの値が同一となることで、通番ｉの格納領域に格納されている業務データがそれぞれのテーブル更新プロセスによってほぼ同時に更新され（アクセスの競合が発生し）、前記業務データに矛盾等が生ずる恐れがある。

この問題は、変数ｘのアクセス（読み出し及び更新）に対して排他制御を行うか、或いは、個々のテーブル更新プロセスによる業務データの更新に対して個々の格納領域を単位として排他制御を行うことで解決できるが、本実施形態では、業務データの更新に対する排他制御を行っている。すなわち、まずステップ５２では、先のステップ４２でキューから取り出した更新用データに対応するモニタ項目を判断し、状況管理テーブル群の各テーブルの中から判断したモニタ項目に対応するテーブルを選択した後に、選択したテーブルのうちの通番ｉの格納領域に対し、他のテーブル更新プロセスによる業務データの更新を禁止する情報を設定することで、他のテーブル更新プロセスによる通番ｉの格納領域のアクセスをロックする。

次のステップ５４では、他のテーブル更新プロセスによる業務データの更新を禁止する情報を設定した格納領域に格納されている業務データを、先のステップ４２でキューから取り出した更新用データに基づいて更新する。そしてステップ５６では、業務データの更新を行った格納領域に対し、先のステップ５４で行った設定を解除し、他のテーブル更新プロセスによる業務データの更新を可能とする。テーブル更新処理は以上の処理により一旦終了するが、次回のプログラム実行期間に再度実行されるので、上述したように、キューから更新用データを取り出し、業務データ更新対象の格納領域の通番ｉを決定し、取り出した更新用データに対応するテーブルの通番ｉの格納領域に対して業務データの更新を行う処理が、ｎ個のテーブル更新プロセスにより、互いに並列に繰り返し行われることになる。

本実施形態に係るテーブル更新処理では、業務データに矛盾等が生ずることを防止するために、業務データの更新に対して排他制御を行っており、これに伴ってオーバヘッドは増大するものの、前述のように、複数のテーブル更新プロセスが読み出した変数ｘの値が同一となってアクセスの競合が発生することは非常に稀なケースであり、個々のテーブル更新プロセスは、殆どの場合、アクセスの競合によって業務データの更新が待たされることなく、キューから取り出した更新用データに基づく業務データの更新をごく短時間で完了させることができるので、排他制御を行うことによる処理効率の低下を必要最小限に抑制し、状況管理テーブル群の各テーブルに登録されている業務データの更新を高い処理効率で行うことができる。

また、オペレータによってキーボード２０が操作されることで、特定のモニタ項目の情報のディスプレイ１８への表示が指示されると、記憶部１２Ｃに記憶されているデータ統合出力プログラムがＣＰＵ１２Ａによって実行されることで、図４に示すデータ統合出力処理が行われる。このデータ統合出力処理では、まずステップ９０において、オペレータによってディスプレイ１８への情報の表示が指示されたモニタ項目を認識する。次のステップ９２ではメモリ１２Ｂ上の稼働数ｎの記憶領域からテーブル更新プロセスの稼働数ｎを読み出す。またステップ９４では、状況管理テーブル群の各テーブルのうち、ステップ９０で認識したモニタ項目に対応するテーブルの通番１〜ｎ（このときのｎの値はステップ９２で読み出した値）の格納領域に格納されている業務データを各々取得する。

次のステップ９６では、ステップ９４で通番１〜ｎの格納領域から取得したｎ個の業務データを統合する。図６に示すように、個々の格納領域に格納されている業務データは、複数種の主キー毎にデータが分けられており、ステップ９６におけるｎ個の業務データの統合は、主キーが同一のデータを単位とし、データの種類に応じて、例えばｎ個のデータの合計値や平均値等を演算することによって行われる。そしてステップ９８では、統合後の業務データを、モニタ項目に対応する表示形式（例えばグラフ形式や表形式等）でディスプレイ１８に表示し、データ統合処理を終了する。このデータ統合処理はオペレータによって指示される毎に行われ、別のモニタ項目が指定された場合には、指定された別のモニタ形式に対応する業務データがディスプレイ１８に表示されることになる。

これにより、オペレータは、各モニタ項目に対応する業務データを順にディスプレイ１８へ表示させる操作を行い、ディスプレイ１８に順に表示された業務データを各々参照する等により、特定金融機関全体としての資金繰りや決済の現在の状況を把握することができる。先に説明したように、本実施形態では、状況管理テーブル群の各テーブルに登録されている業務データを高い処理効率で更新することができるので、電文受信処理によってキューに投入された更新用データがテーブル更新処理によってキューから取り出される迄の時間（更新用データがキューに滞留している時間）を短縮することができる。従って、或る金融取引の内容が取引明細系ＤＢに反映されてから（前記金融取引が確定してから）前記金融取引の内容がディスプレイ１８に表示される業務データに反映される迄の時間が短縮され、特定金融機関全体としての資金繰りや決済の現在の状況を、オペレータがより正確に把握することができる。

なお、図４に示すデータ統合出力処理では、オペレータによって業務データの表示が指示される毎に、対応するテーブルから業務データを取得して表示しているが、これに限られるものではなく、状況管理テーブル群の各テーブルに登録されている業務データはｎ個のテーブル更新プロセスによるテーブル更新処理によって適宜更新されているので、特定のモニタ項目に対応する業務データがディスプレイ１８に表示されている間、特定のモニタ項目から業務データを取得し、取得した業務データに基づいてディスプレイ１８の表示を更新する処理を一定時間毎に繰り返すようにしてもよい。上述したように、データ統合出力処理は状況管理テーブル群の各テーブルから業務データを読み出すのみで、業務データの更新は行わないので、上記のように一定時間毎に状況管理テーブル群の何れかのテーブルからデータを読み出したとしても、アクセスの競合によって処理効率が低下することはない。

ところで、キューに保持される更新用データの数は、電文受信処理によって単位時間にキューに投入される更新用データの数と、ｎ個のテーブル更新プロセスによって単位時間にキューから取り出される更新用データの数との大小関係によって変化し、サーバ・コンピュータ１２がコンピュータ・ネットワーク１４や日銀システム２４から単位時間に受信する電文数が大幅に増大すると、キューに保持される更新用データの数が増大し、多数の更新用データがキューに滞留することで、或る金融取引の内容が取引明細系ＤＢに反映されてから前記金融取引の内容がディスプレイ１８に表示される業務データに反映される迄の時間が長時間化することになる。

これに対して本実施形態では、先に説明した稼働プロセス数管理処理(図５)のステップ６８でスタートさせたタイマがタイムアウトすると、これをトリガとして稼働プロセス数管理処理が再度実行される。タイマのタイムアウトをトリガとして稼働プロセス数管理処理が実行された場合は、先のステップ６０の判定が否定されてステップ７０へ移行し、キューに保持されている（滞留している）更新用データの数Ｓを取得する。次のステップ７２では、ステップ７０で取得した更新用データの数Ｓを予め設定された最大値Ｓmax及び最小値Ｓminと各々比較し、その大小関係に応じて分岐する。

ここで、ステップ７０で取得した更新用データの数Ｓが最大値Ｓmax以下で、かつ最小値
Ｓmin以上であった場合には、キューに保持されている更新用データの数Ｓは適切であり
、テーブル更新プロセスの稼働数ｎの変更は不要と判断できるので、ステップ７０からステップ８４へ移行し、タイマをスタートさせて稼働プロセス数管理処理を終了する。この場合、タイマが再度タイムアウトする一定時間後に、更新用データの数Ｓが適切か否かが再度判定されることになる。

一方、ステップ７０で取得した更新用データの数Ｓが最大値Ｓmaxよりも大きい場合には
、キューに保持されている更新用データの数Ｓは過大となっており、ディスプレイ１８に表示される業務データの更新の遅延時間が大きくなっていると判断できるので、ステップ７２からステップ７４へ移行し、オペレーティング・システムに対してテーブル更新プロセスを１個追加生成するよう指示する。これにより、オペレーティング・システムによってテーブル更新プロセスが１個だけ追加生成され、追加生成されたテーブル更新プロセスが稼働を開始する。また、ステップ７６ではメモリ１２Ｂ上の稼働数ｎの記憶領域に記憶されているテーブル更新プロセスの稼働数ｎを１だけインクリメントする。そして、ステップ８４でタイマをスタートさせて稼働プロセス数管理処理を終了する。

この場合、互いに並列にテーブル更新処理を行うテーブル更新プロセスの数が１つ増加す
ると共に、状況管理テーブル群の各テーブルに設けられているｍ個の格納領域のうち、業務データが更新される格納領域の数も１つ増加することになり、キューからの更新用データの取り出し速度が増大することで、キューに滞留している更新用データの数Ｓの増加が抑制される。また、サーバ・コンピュータ１２が受信する電文数の増大に対してテーブル更新プロセスの追加数（１個）が十分でない場合は、タイマが再度タイムアウトする一定時間後にも、更新用データの数Ｓが最大値Ｓmaxよりも大きい状態が継続していることで
テーブル更新プロセスが更に追加生成され、テーブル更新プロセスの数がサーバ・コンピュータ１２の受信電文数に応じて最適化されることになる。

また、ステップ７０で取得した更新用データの数Ｓが最小値Ｓminよりも小さい場合には
、ディスプレイ１８に表示される業務データの更新の遅延時間は十分に小さいので、サーバ・コンピュータ１２の処理能力をサーバ・コンピュータ１２が実行している別の処理（或いは取引明細系ＤＢの更新）に振り分けることが望ましい。このため、更新用データの数Ｓが最小値Ｓminよりも小さい場合はステップ７２からステップ７８へ移行し、オペレーティング・システムに対し、稼働中の１個のテーブル更新プロセスの稼働を停止させるよう指示する。これにより、オペレーティング・システムによって１個のテーブル更新プロセスの稼働が停止される。

また、テーブル更新プロセスの数の減少に伴ってメモリ１２Ｂに記憶されているテーブル更新プロセスの稼働数ｎを更新すると、状況管理テーブル群の各テーブルに設けられているｍ個の格納領域のうちの通番ｎの格納領域で業務データの更新が停止されると共に、通番ｎの格納領域がデータ統合出力処理(図４)による業務データの統合対象からも除外されるので、次のステップ８０では、各テーブルの通番ｎの格納領域に格納されている業務データを、同一テーブルの他の格納領域に格納されている業務データに統合する。そして、次のステップ８２ではメモリ１２Ｂ上の稼働数ｎの記憶領域に記憶されているテーブル更新プロセスの稼働数ｎを１だけデクリメントし、ステップ８４でタイマをスタートさせて稼働プロセス数管理処理を終了する。

この場合、互いに並列にテーブル更新処理を行うテーブル更新プロセスの数が１つ減少すると共に、状況管理テーブル群の各テーブルに設けられているｍ個の格納領域のうち、業務データが更新される格納領域の数も１つ減少することになり、キューからの更新用データの取り出し速度が減少する分、サーバ・コンピュータ１２の処理能力がサーバ・コンピュータ１２が実行している別の処理（或いは取引明細系ＤＢの更新）に振り分けられることになる。

なお、上記では更新用データに基づいて業務データを更新するにあたり、キューから更新用データを取り出す都度、先の(１)式の演算を行って業務データの更新を行う格納領域を決定する態様を説明したが、本発明はこれに限定されるものではなく、特に、稼働中にテーブル更新プロセスの数を増減させない等の場合には、個々のテーブル更新プロセスに対し、業務データの更新を行う格納領域の通番として互いに異なる通番を設定しておき、個々のテーブル更新プロセスが、設定された通番の格納領域に格納されている業務データを更新するようにしてもよい。この場合、アクセスの競合は起こり得ないので、図３のステップ５２,５６のような排他制御を省略することができ、処理効率を更に向上させることができる。

また、上記では本発明に係る更新対象データとして特定金融機関全体としての資金繰りや決済の状況を表す業務データを、更新用データとして業務データを更新するためのデータを例に説明したが、本発明はこれに限定されるものではなく、更新対象データとして任意のデータを適用可能である。また、更新用データは、更新対象データの更新に間接的に使用可能なデータであってもよく、処理手段が保持手段から取り出した更新用データに対し
て何らかの処理を行うことで、更新対象データの更新に直接使用できるデータが生成されるデータであってもよい。

また、上記では本発明に係るデータ処理プログラム（に対応する電文受信プログラム、テーブル更新プログラム、データ統合出力プログラム、及び、稼働プロセス数管理プログラム）がサーバ・コンピュータ１２の記憶部１２Ｃに予め記憶（インストール）されている態様を説明したが、本発明に係るデータ処理プログラムは、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ、ＭＴ等の記録媒体に記録されている形態で提供することも可能である。

本実施形態に係るコンピュータ・システムの概略構成を示すブロック図である。電文受信処理の内容を示すフローチャートである。テーブル更新処理の内容を示すフローチャートである。データ統合出力処理の内容を示すフローチャートである。稼働プロセス数管理処理の内容を示すフローチャートである。本実施形態に係る取引明細管理システムにおける状況管理テーブル群の構成及びその更新処理を説明するための説明図である。従来の取引明細管理システムにおける処理を説明するための説明図である。

１０コンピュータ・システム
１２サーバ・コンピュータ
１２Ｂメモリ
１２Ｃ記憶部
１４コンピュータ・ネットワーク
１８ディスプレイ
２０キーボード
２４日銀システム

Claims

更新対象データの更新に用いられる更新用データが順に入力され、入力された更新用データを保持する保持手段と、
前記更新対象データを格納する複数の記憶手段と、
１または複数のプロセスを制御する制御部であって、前記１または複数のプロセスは、前記保持手段から前記更新用データを取り出し前記複数の記憶手段のいずれかの記憶手段に格納されている前記更新対象データを、前記取り出した更新用データに基づいて更新する処理を繰り返し、前記制御部は、前記保持手段に保持されている更新用データの数を取得し、前記取得された数が第１の値よりも小さければ、前記１または複数のプロセスの中から選択を行い選択されたプロセスを停止させ、前記複数の記憶手段の一部に格納されている更新対象データを他の記憶手段に統合し、前記記憶手段の一部を除外し減少させ、前記取得された数が前記第１の値よりも大きな第２の値より大きければ、前記記憶手段の数を増加させ、新たにプロセスを起動させて前記処理を繰り返させる制御を行なう制御部とを有することを特徴とするデータ処理装置。
前記制御部の起動時にタイマが起動され、前記タイマのタイムアウトをトリガとして、前記制御部は前記制御を行なった後に前記タイマを起動することを特徴とする請求項１に記載のデータ処理装置。
前記制御部が新たに起動させるプロセスの数と増加させる記憶手段の数とは同じであり、前記制御部が停止させるプロセスの数と前記除外させ減少させる一部の記憶手段の数は同じであることを特徴とする請求項１に記載のデータ処理装置。