JPWO2006080058A1 - 電文処理装置 - Google Patents

電文処理装置 Download PDF

Info

Publication number
JPWO2006080058A1
JPWO2006080058A1 JP2007500371A JP2007500371A JPWO2006080058A1 JP WO2006080058 A1 JPWO2006080058 A1 JP WO2006080058A1 JP 2007500371 A JP2007500371 A JP 2007500371A JP 2007500371 A JP2007500371 A JP 2007500371A JP WO2006080058 A1 JPWO2006080058 A1 JP WO2006080058A1
Authority
JP
Japan
Prior art keywords
message
message processing
processing
request
processing request
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.)
Pending
Application number
JP2007500371A
Other languages
English (en)
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
Publication of JPWO2006080058A1 publication Critical patent/JPWO2006080058A1/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/546Message passing systems or structures, e.g. queues

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

複数クライアント1から同時大量に発生する電文処理要求c1を、各クライアント接続装置2では複数の受付部A1で電文種別毎に一次集約すると共に電文処理要求c1の電文を入力電文記憶装置4に一括格納し、更に該一次集約した電文処理要求c2を電文処理要求部A2で二次集約して電文種別毎処理装置3に電文処理要求c3として転送する。電文種別毎処理装置3では複数のクライアント接続装置2から電文処理要求c3を、電文種別毎の電文処理要求受付部A3が受け付けて更に三次集約し、対応する電文種別毎の電文処理部A4に電文処理要求c4として電文処理の要求が発生したことを通知する。電文処理要求c4を受けた電文処理部A4は、入力電文記憶装置4から未処理の電文データを一括して読み出して対応した処理を行う。クライアントからは、受付部A1にて電文処理要求を受付けた際に通知した通番により、随時、電文の処理状態の確認や処理結果の取得を行う。

Description

本発明は、電文処理装置に関し、特にWEBや金融・流通のオンライン処理、大規模ネットワークのオペレーションシステム等の多数のクライアントから同時に発生する処理要求やイベント通知等の電文をリアルタイムに処理する電文処理装置に関するものである。
ネットワークに接続されたクライアント(エンドユーザー端末や装置等)から同時多発する大量の電文(処理の要求やイベント通知等)をリアルタイムに処理するシステムにおいては、電文単位にそれを処理するタスクを割り当てて、各電文に対する処理を同時並行で多重処理することになるが、この場合、処理の多重度に応じて、システム資源は比例して大きくしなければならなかった。
また、電文の同時並行処理は、従来より、複数の処理装置を用いて負荷分散を行うシステムにより実現されているが、電文の処理過程において参照・更新するデータをファイルやデータベース等で一元管理する場合、その並行処理によるデータ参照・更新(アクセス)が相互に競合し合いボトルネックとなる。このため、分散処理の効果が得られずに処理能力が期待されたより向上しない場合が多く、参照・更新を行うファイルやデータベースの複製を多数設けて、同期化させるような複雑なシステム形態を採らなければならなかった。
一方、マルチ・ユーザー・データ処理環境において使用される待機深さの制限並行制御として、競合関係を解決する際に考慮する待機木の深さを、予め決められた深さに制限する方法がある。これは、集中トランザクション処理システムへの実施例においては、実数関数によって代表されるトランザクション特有の情報が、予め決められた深さを超えたトランザクション間のコンフリクトの場合に、どのトランザクションを再始動するかを決めるのに使用され、分散トランザクション処理システムでは、トランザクションTの現在の長さは,各大域トランザクションに割り当てられた開始時間に基づいており、この開始時間には各サブトランザクションのスタートアップ・メッセージも含んでいる並行制御方法である(例えば、特許文献1参照。)。
さらに、所定数のスレッドが生成され、その情報がスレッド惰報記憶部に登録され、生成されたスレッドの内、空きスレッドが空きスレッドリストに登録され、外部からのスレッドを必要とする処理要求が待機リストに登録され空きスレッドリストを監視して空きスレッドの発生を待って処理を実行すると共に、外部からのスレッドを必要としない処理要求は待機リストを介さずに受け付けられ処理を実行するスレッド管理システム及び管理方法並びに管理プログラムを記録した記録媒体がある(例えば、特許文献2参照。)。
特開平6-103132号公報 特開2000-293385号公報
このように、並行処理でのファイルやデータベースへのアクセス競合が想定されるシステムにおいては、これらの競合を回避しなければ、例え複数の処理装置を設けて多重分散処理を行っても、その並行処理によるデ一タ参照・更新のためのアクセス競合がボトルネックとなるため、その多重分散処理の効果が得られなかった。
また、そのアクセス競合を回避するためには、参照・更新を行うファイルやデータベースの複製を多数設けて、それらを自動的に同期化させるような複雑なシステム形態を採らなければならなかった。
従って本発明は、複数の処理装置を設けた多重分散処理におけるアクセス競合の課題を解決することにより、同時多発する大量の電文をリアルタイムに処理でき、且つ、クライアント側のユーザ数やイベント数の増加、コンテンツの大容量化に対応可能な、スケーラビリティを確保した電文処理装置を提供することを目的とする。
(1)上記の課題を解決するため、本発明に係る電文処理装置は、複数のクライアントから同時に電文及びその電文処理要求を受け付けて該電文処理要求を集約すると共に、該電文処理要求に係る電文を、入力電文記憶装置に一括格納する第1手段と、該第1手段で集約した電文処理要求を受けて更に一回以上集約すると共に、該集約した電文処理要求に基づき該電文処理要求に対応した電文を、該入力電文記憶装置から一括して読み出して対応した処理を行う第2手段とを備え、クライアントからの電文処理要求を受付けた時に通知した通番により、クライアントから電文処理状態や電文処理結果を随時、照会可能としたことを特徴としている。
すなわち、第1手段では、複数のクライアントが同時に電文とその電文処理要求又は依頼(以下、「要求」と総称する。)を送出したとき、その電文処理要求を集約し、さらに各電文を入力電文記憶装置に一括して格納しておく。
そして、第2手段では、上記第1手段で集約した電文処理要求をさらに集約する。この時の集約回数は1回以上であればよい。そして、このように集約した電文処理要求に基づいて対応した電文を、入力電文記憶装置から一括して読み出して処理を行う。
そして、クライアントからの電文処理要求を受付けた時に通知した通番により、クライアントから電文処理状態や電文処理結果を随時、照会可能としたものである。
このようにして、電文自体は入力電文記憶装置に格納しておき、電文処理要求のみを集約してから電文処理を行うので、入力電文記憶装置へのアクセス競合状態を排除することが可能になると共に、不要な電文の転送処理を排除することができる。
(2)また、本発明では、複数のクライアントから同時に電文処理要求を受け付けて該電文処理要求を電文種別毎に一次集約すると共に、該電文処理要求に係る電文を入力電文記憶装置に電文種別毎に一括格納する複数の電文受付部、及び該一次集約した電文処理要求を受けて、電文種別毎に更に二次集約する電文処理要求部を、各々が含む複数のクライアント接続装置と、該電文処理要求に基づき各クライアント接続装置で生成された電文処理要求を受けて、それらを更に三次集約する電文処理要求受付部、及び該電文処理要求受付部から該三次集約した電文処理要求を受けて、該電文処理要求に対応した電文データを、該入力電文記憶装置から一括して読み出し該電文種別に対応した処理を行う電文処理部を、各々が含む複数の電文種別毎処理装置と、を備えた電文処理装置が提供される。
ここで、上記(2)の原理を、図1を参照して以下に説明する
まず、本発明に係る電文処理装置は大略、各々が複数のクライアント1に接続された複数のクライアント接続装置2(以下、この装置を「サーバ」と呼ぶことがある。)と、各々が複数のクライアント接続装置2に接続された複数の電文種別毎処理装置3とで構成されており、次のように4階層から成っている。
第1階層は電文受付部A1_1、A1_2、A1_n(以下、符号「A1」で総称することがある。)、第2階層は電文処理要求部A2、第3階層は電文処理要求受付部A3_1及びA3_2(以下、符号「A3」で総称することがある。)、そして最後の第4階層は電文処理部A4_1及びA4_2(以下、符号「A4」で総称することがある。)である。
複数のクライアント1は、それぞれがクライアント接続装置2_1、2_2の電文受付部A1(第1階層)との間で電文処理要求やその応答等のイベントc1の授受ができるようになっている。
また、各クライアント接続装置2の複数の電文受付部A1は、イベントc2を電文処理要求部A2(第2階層)に通知できるように接続されている。
更に、各電文処理要求部A2は、イベントc3を、電文種別1処理装置3_1及び電文種別2処理装置3_2の各電文処理要求受付部A3(第3階層)に通知できるように接続されている。
電文種別1処理装置3_1及び電文種別2処理装置3_2には、その電文種別に応じた電文処理部A4(第4階層)が設けられており、各電文処理部A4は対応する電文処理要求受付部A3からイベントc4を受けられるようになっている。
一方、電文処理に係る電文データへのアクセスについては、各電文受付部A1(第1階層)が入力電文記憶装置4にアクセスd1、処理結果記憶装置5にアクセスd2を行い、各電文処理部A4(第4階層)が入力電文記憶装置4にアクセスd3、管理情報記憶装置6にアクセスd4、処理結果記憶装置5にはアクセスd5ができるように、それぞれが接続されている。
上記の構成において、複数のクライアント1から電文処理要求のイベントc1があると、各クライアント接続装置2の複数の電文受付部A1が、そのイベントc1を受けて、それらの電文データ(以下、単に「電文」と呼ぶ場合がある。)を電文種別毎に集約して入力電文記憶装置4に一括して書き込む(アクセスd1)と共に、該電文処理要求が発生した事を電文種別毎に集約し(一次集約)、対応する電文処理要求部A2に向けて、電文処理要求のイベントc2を通知する。
なお、集約とは、該電文処理要求があったことを示す情報に変換することであり、その件数を合計することでは無い。例えば、予め定めた時間内に100件の電文処理要求があったとすると、電文処理要求のイベントc2で100件と通知するのでは無く、
100件の電文処理要求があった事実のみを対応する電文処理要求部A2に知らせる。以下、集約についての定義は、同様である。
各電文処理要求部A2は、複数の電文受付部A1から通知された電文処理要求のイベントc2を電文種別毎に更に集約し(二次集約)、その電文種別に応じて電文種別毎処理装置3の電文種別1処理装置3_1又は電文種別2処理装置3_2の電文処理要求受付部A3に向けて、電文処理要求のイベントc3を通知する。
各クライアント接続装置2の電文処理要求部A2から電文処理要求のイベントc3を受けた各電文処理要求受付部A3は、各々がその要求の受付処理を行って更に集約し(三次集約)、対応する電文処理部A4に電文処理要求のイベントc4を通知してその電文の処理を要求する。
該三次集約された電文処理要求のイベントc4を受けた各電文処理部A4は、該電文処理要求に基づき、入力電文記憶装置4から未処理の電文データを一括して読み出す(アクセスd3)。なお、その処理に必要な管理情報を管理情報記憶装置6から参照・更新(アクセスd4)して、それらの電文データを処理し、その処理結果を処理結果記憶装置5へ一括して格納(アクセスd5)する。
従って、電文種別に対応した電文処理部A4は、該電文受付部A1が該電文処理要求に係る電文を電文種別毎に一括格納した該入力電文記憶装置4から、一度のアクセスで処理対象となる大量の電文データを一括して読み出して処理するので、段階的に集約して転送する経路での処理対象電文データの転送が不要となり、アクセス競合を極めて少なくすることができる。
また、本発明に係る電文処理装置は、同時多発した大量の電文処理要求をクライアント接続装置の各受付部から電文種別毎処理装置の各電文処理部に伝える手段として、該電文処理要求を段階的に集約しながら、集約規模を拡大して通知することにより、スケーラビリティを確保すると共にアクセス競合の問題を解決している。
従って、上記の大量の電文処理要求を各電文処理部に伝える手段、すなわち、各電文受付部の一次集約、各電文処理要求部の二次集約及び各電文処理要求受付部の三次集約は、機能的のみならず物理的境界等を考慮して段階的に集約する手段の一つであり、上記の原理説明に限定されるものではなく、その電文処理要求を、一括処理する電文処理部の機能に沿って、電文種別毎の他に、例えば、電文内容毎等で段階的に集約する構成を採ることでも同じ効果が得られる。
(3)上記(2)における電文処理装置の各電文受付部は、該クライアントから新規に要求された電文及びその電文処理要求に通番を付加する通番処理と、予め定めた件数又は予め定めた時間になるまで該電文を一旦保存し、該件数又は該時間に達した時、それまで保存した電文を該通番と共に該入力電文記憶装置に一括して書き込み、要求元のクライアントには該通番を通知することができる。
(4)上記(3)における電文処理装置の各電文受付部は、各クライアントから該通番を用いた電文種別毎の確認要求を受けた時、該入力電文記憶装置から該通番に対応する電文処理状態を読み出して該クライアントに応答することができる。
ここで、上記(3)及び(4)の原理を、図2を参照して以下に説明する
各電文受付部A1は、複数のクライアント1から新規の電文処理要求c1_1をその電文と共に受けると、その電文に通番を付加する通番採番処理(以下、「処理」を省略することがある。)a1_1を行い、その電文を一時保存する。各電文受付部A1は、予め定めた受付件数又は予め定めた時間の何れかが先に達するまで、この通番採番a1_1を実行すると(一次集約)、それまで一時格納したその通番若しくはその通番に関連付けた情報を含んだ電文を入力電文記憶装置4へ一括格納a1_2する(電文格納d1_1)。
次に、電文受付部A1はここで一次集約された新規要求c1_1の各クライアント1に対して、一斉に受付応答a1_3を行うことにより、それぞれの新規受付応答c1_2を返して対応する通番を通知し、続いて、電文受付部A1は電文処理要求a1_4を行い、電文処理要求部A2へ処理対象の電文が発生したことを電文処理要求c2で通知する。なお、この電文処理要求c2と新規受付応答c1_2の実行順序はどちらが先でもよい。
このようにして、第1階層である電文受付部A1の各々は、各クライアント1から送られて来た新規要求c1_1を、通番採番a1_1を行いながら予め定められた一定時間内又は件数内で一次集約すると共に、その通番を含めて一時格納された電文を入力電文記憶装置4に一括して保存する。また、各クライアント1に対しては、その通番を通知する新規受付応答c1_2を返す。
従って、その後、電文種別毎の確認要求を受けたとき、入力電文記憶装置4からその通番をキーとして、電文処理状態を読み出してクライアントに応答することで、クライアント側の要求内容と電文処理装置側の処理内容との同期処理が可能となる。
(5)上記(2)における電文処理装置の電文処理要求部及び電文処理要求受付部は、それぞれ、該電文処理要求を受けて、それぞれに予め定められた時間まで待受処理を行うことにより各集約を行い、各々が集約した電文処理要求をそれぞれ該電文処理要求受付部及び該電文処理部へ送って処理対象の電文が発生したことを通知することができる。
次に、上記(5)の原理を、図3を参照して説明する
各クライアント接続装置2の電文処理要求部A2は、同じクライアント接続装置2内の複数の電文受付部A1から電文種別毎に一次集約された複数の電文処理要求c2を受けると、それらを、予め定めた一定時間内で待受処理a2_1を行い、電文種別毎に更に集約(二次集約)し、その後、電文処理要求a2_2を実行することにより、電文種別に対応した電文種別毎処理装置3の電文処理要求受付部A3へ電文処理要求c3を通知する。
次に、各々の電文種別毎処理装置3の電文処理要求受付部A3は、電文処理要求部A2で二次集約された電文処理要求c3を複数のクライアント接続装置2から受けると、それらを、予め定めた一定時間の待受処理a3_1を電文種別毎に行って更に集約(三次集約)し、その後、電文処理要求a3_2を実行することにより、その電文種別に対応した各々の電文処理部A4へ電文処理要求c4を通知する。
このようにして、各電文処理要求部A2と各電文処理要求受付部A3は、各電文受付部A1で受け付けられ電文種別毎に一次集約された電文処理要求c2を電文種別毎に、二次及び三次と段階的に集約規模を拡大し、その電文種別に対応した各々の電文処理部A4へ電文処理要求c4として通知する。
このようにして、大量のイベントc1は、各々の電文受付部A1、各電文処理要求部A2、更に各電文処理要求受付部A3によって段階的に集約し、一つの電文処理要求c4として対応する電文処理部A4に転送される。
従って、その電文処理要求c4内の電文処理におけるアクセス競合が無くなると共に、処理件数当たりのファイルやデータベースへのアクセス回数が極めて少なくなり、アクセス効率が向上するので、クライアント数やイベント数の増加に柔軟に対応できる。
(6)上記(5)における電文処理装置の電文処理要求部及び電文処理要求受付部は、それぞれ、該電文処理要求を受けると、対応する電文処理要求が発生したことを示す電文発生フラグ、及び電文の処理要求が発生したことを示す処理発生フラグがOFF状態であることを各々が確認したときのみ該電文発生フラグ、及び該処理発生フラグをON状態に設定し予め定められた時間まで該待受処理を行い、各々が集約した電文処理要求をそれぞれ該電文処理要求受付部及び該電文処理部へ送って処理対象の電文が発生したことを通知すると共に、両フラグをOFF状態に戻すことができる。
(7)上記(4)における電文処理装置の電文処理部は、該電文処理要求を受けて、該入力電文記憶装置に格納されている未処理の電文を一括して読み出すと共に、管理情報記憶装置から各電文の処理に必要な情報を参照・更新して各電文を処理し、それらの処理結果を処理結果記憶装置に一括して格納し、更に該入力電文記憶装置中の対応する電文を、処理済として更新することができる。
次に、上記(7)の原理を、図4を参照して説明する
電文種別毎処理装置3の電文処理部A4は、電文処理要求受付部A3から三次集約された電文処理要求c4を受けると、それをトリガーとして、未処理電文一括取得a4_1を実行し、入力電文記憶装置4に格納されている未処理の電文を一括して読み出す未処理電文読出d3_1を行う。次に、電文処理a4_2の実行に移り、管理情報記憶装置6から各電文の処理に必要な管理情報を参照・更新d4をして、各電文データを処理する。電文処理a4_2が終了すると、電文処理結果保存処理a4_3に移り、それらの処理結果を処理結果記憶装置5に一括して格納d5する。
このようにして、電文種別毎に設けられた各々の電文処理部は、該電文処理要求を受けて、該入力電文記憶装置に格納されている未処理の電文を一括して読み出すと共に、該管理情報記憶装置から各電文の処理に必要な情報を参照・更新して、各電文を処理し、それらの処理結果を処理結果記憶装置に一括して格納し、更に該入力電文記憶装置中の対応する電文を、処理済として更新する。
従って、電文受付部A1はクライアントからの状況確認要求や結果取得要求に応じて、入力電文記憶装置4と処理結果記憶装置5から読み出して要求元のクライアントに応答できる。
上記のように、本発明に係る電文処理装置は、処理対象の大量の電文に一括してアクセスするので、アクセス競合は、その集約された単位内では無くなり、一件毎にアクセスする従来例に比べて極めて少なくなる。
また、第1階層の電文受付部A1で電文データを一括保存し、最終階層である第4階層の電文種別毎処理部へは、三次集約した電文処理要求のみを転送し、途中、第2、第3階層での電文データの転送処理が必要ないので、電文の処理効率を更に向上させることができる。
また、電文種別毎に集約した電文処理要求を受けることは必須ではなく、対応する電文処理部の機能に合わせて、処理内容毎に段階的に集約した電文処理要求を受ける構成としてもその効果が変わるものではない。
(8)上記(7)における電文処理装置の電文受付部は、各クライアントから電文種別毎の結果取得要求を受けた時、該処理結果記憶装置から処理結果を読み出して該クライアントに応答することができる。
これを、再び図2及び図3を参照して以下に説明する
まず、クライアント1からのポーリングなどにより、先の新規受付応答c1_2で通知した通番を含む状況確認要求c1_3が送られて来ると、電文受付部A1は処理状況取得a1_5を実行して、入力電文記憶装置4からその通番に対応する処理状態データの電文処理状態取得d1_2を行う。次に、電文受付部A1は、その取得した処理状態を基に処理状況応答a1_6を実行して、状況確認要求c1_3があったクライアント1に対して状況確認応答c1_4を返す。
また、クライアント1から、先に通知した通番を含む結果取得要求c1_5が送られて来ると、電文受付部A1は処理結果取得a1_7を実行し、処理結果記憶装置5からその通番に対応する電文の電文処理結果取得d2を行う。次に、電文受付部A1は処理結果応答a1_8を実行して、その取得した電文の処理結果を基に結果取得要求c1_5があったクライアント1に対して結果取得応答c1_6を返す。
このようにして、新規要求c1_1から始まり結果取得応答c1_6で終わる一つのトランザクションは、新規要求c1_1の電文処理要求が一次集約されて電文処理要求部A2に通知され、最終的には電文種別毎処理装置3の電文処理部で処理されるが、残る状況確認要求c1_3(上記(4)参照。)と結果取得要求c1_5の電文処理要求については、電文受付部A1が上記のようにして状況確認応答c1_4と結果取得応答c1_6の応答をすることで完結する。
従って、新規要求c1_1とその後の状況確認要求c1_3及び結果取得要求c1_5、すなわち、電文処理の内容によって、その処理を該電文受付部A1と該電文処理部A4に局在化させることにより、電文受付部A1が処理する電文については、電文処理部A4がアクセスする必要が無くなるので、その処理に係るデータへのアクセス競合を更に低減することができる。
本発明に係る電文処理装置は、各受付部が同時多発する大量の電文処理要求を受け付けて、それらの電文を入力電文記憶装置に格納すると共に、その電文処理要求を集約して各電文処理部へ通知し、各電文処理部が、その集約された電文処理要求を受けて、未処理電文を入力電文記憶装置から一括して読み出して処理するので、電文処理件数当たりのファイルやデータベースへのアクセス回数が極少化され、アクセス効率が向上するという利点がある。
また、受けた各電文処理部は、各受付部が入力電文記憶装置に格納した電文を、その電文処理要求に基づいて、処理対象となる電文をその同じ入力電文記憶装置から一括して読み出して処理するので、その電文処理要求を段階的に集約する過程においては、それらの電文データ転送処理が不要となる利点がある。
更に、該電文受付部は、該クライアントから新規に要求された電文処理要求に通番を付加して該入力電文記憶装置に一括で書き込みを行うと共に、要求元のクライアントには該通番を通知するので、その通番をキーとしてその後の電文処理を進めることにより、クライアント側の要求内容と電文処理装置側の処理内容との同期処理が可能となる利点がある。
また、各クライアントから新規に要求された電文処理要求を電文処理部が処理し、それに続く同じ通番を含む電文処理要求を電文受付部が処理することにより、電文受付部が処理する電文については、電文処理部がアクセスする必要がないので、その処理に係るデータへのアクセス競合を更に低減可能となる利点がある。
また、該電文処理要求部及び該電文処理要求受付部は、各々が前階層で集約された電文処理要求を受けて、それぞれに予め定められた時間まで待受処理を行うことにより該二次集約又は三次集約を行うので、段階的に集約規模を拡大することが容易であるという利点がある。
また、該電文処理部は、管理情報記憶装置から各電文の処理に必要な情報を参照・更新をして、各電文データを処理し、それらの処理結果を処理結果記憶装置に一括して格納し、更に入力電文記憶装置の対応する電文を、処理済として更新するので、電文受付部はクライアントからの状況確認要求や結果取得要求に応じて、入力電文記憶装置と処理結果記憶装置から読み出して要求元のクライアントに応答できるという利点がある。
以下、本発明に係る電文処理装置の実施例を、チケット予約システムを例にとって、図5〜図10を参照して説明する
まず、図5はそのシステム全体の構成例を示しており、その構成は、電文種別毎処理装置3の予約受付処理装置3_1と空席照処理装置3_2を除いて、既に説明した図1のシステム構成と同様である。すなわち、図1の電文種別1処理装置3_1及び電文種別2処理装置3_2が、図5では予約受付処理装置3_1及び空席照会処理装置3_2へと、それぞれ電文種別の具体的な例として名称が変更されている以外は同様であり、図5のシステム構成の説明は省略する。
次に、図1〜図3及び図5に示した電文受付部A1の実施例を、図6及び図7に分割して示された処理フローブロック図を参照して以下に説明する。まず、図6に示す複数のクライアント1からの電文種別毎の電文処理要求である予約受付要求と空席照会要求に対する、受付からその応答までの処理フローを説明する。
図6において、クライアント1_11、1_12及び1_13より同時に発生した各々の予約受付要求c1_1及び空席照会要求c1_3は、それぞれの電文と共に、それぞれに対応するクライアント応答スレッドa1_1によって同時並行して受信され、各要求とその電文に通番を付加するための通番採番a1_11の処理が施こされる。
通番が付加された各電文は、一時格納a1_12によって電文種別毎に予約受付電文一時保存領域10_1と空席照会電文一時保存領域10_2(以下、「電文種別毎一時保存領域10_1、10_2」と呼ぶ場合がある。)にそれぞれ一時保存される。
その後、各クライアント応答スレッドa1_1は待受起動a1_13に移り、電文種別毎に予約受付待受スレッドa1_2、又は空席照会待受スレッドa1_3に制御を渡すと共に、完了待合a1_14に移り、予約受付待受スレッドa1_2、又は空席照会待受スレッドa1_3から電文処理要求の送信完了を受けるまで待合わせ状態に入る。
一方、待受起動a1_13で起動された予約受付待受スレッドa1_2、及び空席照会待受スレッドa1_3では、対応する電文種別毎一時保存領域10_1、10_2の保存件数をそれぞれの件数チェックa1_21、a1_31しており、その結果を一時待受a1_22、a1_32に渡す。各一時待受a1_22、a1_32では、その件数が予め定めた件数に達した時、及び予め定めた待受時間を超過した時の何れか早いタイミングで、電文書込a1_23、a1_33にそのタイミングを通知する。この通知を受けて、各電文書込a1_23、a1_33は対応する電文種別毎一時保存領域10_1、10_2にそれまで保存されていた電文を、一括して入力電文記憶装置4に書き込み(アクセスd1_w)、その後、対応する電文処理要求送信a1_24、a1_34に処理を移す。
各電文処理要求送信a1_24、a1_34では、処理対象の電文があることを、予約受付電文処理要求c2_1、空席照会電文処理要求c2_2として、対応する電文処理要求部A2へ送って通知すると共に、完了待合a1_14状態にあるクライアント応答スレッドa1_1に電文処理要求送信a1_24、a1_34の完了を知らせる。
その電文処理要求送信a1_24、a1_34の完了を受けて、クライアント応答スレッドa1_1は完了待合a1_14状態から受付応答a1_15に移り、クライアント1_11及び1_12に対しては予約受付応答c1_2を、クライアント1_13に対しては空席照会応答c1_4を、それぞれ、対応する通番と共に返す。
このように、第1階層の電文受付部A1は、複数のクライアントから同時多発する大量の電文処理要求を、予め定めた件数、又は予め定めた時間内に受け付けた電文データを電文種別毎に設けられた一時保存領域10_1、10_2に通番を付けて一旦保持し、それらを一括して入力電文記憶装置4に格納(アクセスd1_w)すると共に、電文種別毎に一次集約した電文処理要求(予約受付電文処理要求c2_1、空席照会電文処理要求c2_2)を、対応する第2階層の電文処理要求部A2に通知する。
また、電文受付部A1は、それらの通番を対応するそれぞれのクライアント1へ応答c1_2、c1_4して通知する。そして、それらの通番は一つのトランザクションが完了するまで、すなわち、その通番を取得したクライアント1が、次に説明する電文の処理状況確認や処理結果を取得して完了するまで使用される。
このようにして、電文受付部A1は、各クライアントから新規に要求された電文処理要求を電文と共にその種別毎に通番を付加する通番処理と、予め定めた件数又は予め定めた時間になるまで該電文を待受ける待受処理とで一旦保存し、一定件数又は一定時間に達した時、それまで保存した電文を該通番と共に該入力電文記憶装置に一括で書き込みを行い、要求元のクライアントには該通番を返す。
従って、各クライアント1が、既に電文処理要求が受け付けられた後の状況確認や結果取得を要求する場合は、新規受付応答c1_2で取得した通番を用いて行い、電文処理装置側はそれと同じ通番をキーとして電文処理を進めることにより、クライアント側の要求内容と電文処理装置側の処理内容との同期処理が可能となる。
次に、図7を参照して、複数のクライアント1から既に要求された電文の処理状況の確認要求を同時並行して受けた時の、受付からその応答までの処理フローを説明する。
各クライアント1_11、1_13が取得した通番を用いて予約状態確認c1_5、照会状態確認c1_9を各々が行うと、各クライアント応答スレッドa1_1が、状態読出a1_16を実行して入力電文記憶装置4からその通番に対応する処理状態を読み出し(アクセスd1_r)、次に状態応答a1_17を実行する。
各状態応答a1_17では、予約状態確認c1_5があったクライアント1_11には予約状態応答c1_6、照会状態確認c1_9があったクライアント1_13には照会状態応答c1_10でそれぞれに応答し、処理経過を知らせる。
既に処理が完了している応答を受けたクライアント1_11、1_13は、引き続きその通番を用いて予約結果取得c1_7や照会結果取得c1_11をそれぞれ要求することができる。
各クライアント応答スレッドa1_1は、クライアント1_11、1_13から予約結果取得c1_7、照会結果取得c1_11を受け取ると、それぞれが結果読出a1_18を実行して処理結果記憶装置5からその通番に対応する予約処理結果を読み出し(アクセスd2_r)、次に結果応答a1_19を実行する。
各結果応答a1_19では、対応するクライアント1_11、1_13に予約結果応答c1_8や照会結果応答c1_12で応答し、それぞれの結果を返す。
このようにして、各クライアント1が、新たな電文処理を要求(新規トランザクション発生)した時に電文受付部A1からの新規受付応答c1_2で通番を取得し、その後の電文処理状況の問い合わせや結果取得などを要求する場合は、その通番を用いて行う。電文処理装置側はそれと同じ通番をキーとして電文処理を進めることにより、クライアント側の要求内容と電文処理装置側の処理内容との同期を保ちながら、一つの処理が終了するまで、その通番を用いて処理する。
また、上記のように、電文受付部A1は、予約受付要求c1_1及び空席照会要求c1_3を電文種別毎に一次集約して次の階層に通知すると共に、その他の予約状態確認c1_5、予約結果取得c1_7や照会状態確認c1_9、照会結果取得c1_11については、電文受付部A1が、入力電文記憶装置4や処理結果記憶装置5からその通番に対応する処理状態又は結果を読み出して応答する。
次に、図1〜図3及び図5に示した電文処理要求部A2の実施例を、図8に示した処理フローブロック図を参照して説明する
まず、電文処理要求部A2の受付スレッドa2_1は、電文受付部A1からの予約受付電文処理要求c2_10を受けると、予約受付電文が発生したことを示す発生フラグを発生フラグ設定a2_11が予約受付電文発生フラグ20_1に設定する。但し、発生フラグ設定a2_11は、予約受付待受スレッドa2_2の多重起動を避けるために、発生フラグを設定する前にその発生フラグがOFF状態であることを確認した上でON状態に設定(セット)すると共に待受起動a2_12に移行する。
従って、待受起動a2_12は、発生フラグがOFF状態からON状態に設定された時のみ、予約受付待受スレッドa2_2の起動を行う。なお、発生フラグがON状態であった場合は、予約受付待受スレッドa2_2が既に起動されているので、起動しない。
受付スレッドa2_3は、予約受付電文発生フラグ20_1がON状態の時に予約受付電文処理要求c2_11を受けた場合を示しており、受付スレッドa2_3の発生フラグ設定a2_11は実行せず、且つ予約受付待受スレッドa2_2も起動しないので、待受起動a2_12から予約受付待受スレッドa2_2への矢印付き実線は示されていない。
一方、起動された予約受付待受スレッドa2_2は、一時待受a2_13を行い、予め定められた時間まで待受けてその時間が経過すると、電文処理要求送信a2_14に移行する。
電文処理要求送信a2_14は、予約受付処理装置3_1の電文処理要求受付部A3_1(図5参照)へ処理対象の電文があることを通知し(イベントc3_1)、次にフラグ解除a2_15を起動する。フラグ解除a2_15は、予約受付電文発生フラグ20_1の発生フラグを解除(OFF)状態にする。
次に、受付スレッドa2_4が、空席照会電文処理要求c2_20を受けると、空席照会電文が発生したことを示す発生フラグを発生フラグ設定a2_11が空席照会電文発生フラグ20_2に設定する。但し、発生フラグ設定a2_11は、空席照会待受スレッドa2_5の多重起動を避けるために、上記の予約受付待受スレッドa2_2起動時と同様に、発生フラグを設定する前にその発生フラグがOFF状態であることを確認した上でON状態に設定すると共に待受起動a2_12に移行する。
受付スレッドa2_6は、空席照会電文発生フラグ20_2がON状態の時に空席照会電文処理要求c2_21を受けた場合を示しており、受付スレッドa2_6の発生フラグ設定a2_11は実行せず、且つ空席照会待受スレッドa2_5も起動しないので、待受起動a2_12から予約受付待受スレッドa2_2への矢印付き実線は示されていない。
一方、起動された空席照会待受スレッドa2_5は、一時待受a2_13を行い、予め定められた時間まで待受けてその時間が経過すると、電文処理要求送信a2_14に移行する。
電文処理要求送信a2_14は、空席照会処理装置3_2の電文処理要求受付部A3_2(図5参照)へ処理対象の電文があることを通知し(イベントc3_2)、次にフラグ解除a2_15を起動する。フラグ解除a2_15は、予約受付電文発生フラグ20_2の発生フラグを解除(OFF)状態にする。
このように、電文処理要求部A2は、各電文受付部A1が電文種別毎に一次集約した電文処理要求(イベントc2)を、例えば予め定めた待受け時間(例えば0.5秒)を持つことにより更に集約(二次集約)して、電文種別毎に対応した電文処理要求受付部A3に電文処理要求(イベントc3)として通知する。
次に、図1及び図3〜5に示した電文処理要求受付部A3_1、A3_2の実施例を図9に示した処理フローブロック図を参照して説明する。なお、本実施例では電文種別毎処理装置3に属するものとして、図5のシステム構成例に示したように、予約受付処理装置3_1と空席照会処理装置3_2の二つを挙げており、電文処理要求受付部A3_1とA3_2はそれぞれに対応して設けられている。
まず、予約受付の電文処理要求を受け付ける処理フローから説明する。
電文処理要求受付部A3_1の受付スレッドa3_1は、電文処理要求部A2からの電文処理要求c3_10を受けると、電文の処理要求が発生したことを示す発生フラグを、発生フラグ設定a3_11により予約受付処理発生フラグ30_1に設定すると共に、待受起動a3_12する。但し、発生フラグ設定a3_11は、予約受付待受スレッドa3_2の多重起動を避けるために、その発生フラグがOFF状態である場合に限りON状態に設定すると共に待受起動a3_12に移行する。
従って、待受起動a3_12は、発生フラグがOFF状態からON状態に設定された時のみ、予約受付処理待受スレッドa3_2の起動を行う。なお、予約受付処理発生フラグ30_1がON状態の場合は、予約受付処理待受スレッドa3_2が既に起動されているので、更に起動することはしない。
受付スレッドa3_3は、予約受付処理発生フラグ30_1がON状態の時、電文処理要求c3_11を受けた場合を示しており、この場合は予約受付処理待受スレッドa3_2を起動しないという意味で、待受起動a3_12から予約受付処理待受スレッドa3_2への矢印付き実線が除去されている。
起動された予約受付処理待受スレッドa3_2は、一時待受a3_13を行い、例えば予め定められた時間まで待受けてその時間が経過すると、電文処理要求送信a3_14に移行する。
電文処理要求送信a3_14は、予約受付処理装置3_1の電文処理部A4_1(図5参照)へ処理対象の電文があることを通知(イベントc4_1)すると、次にフラグ解除a3_15を起動する。フラグ解除a3_15は、予約受付電文発生フラグ30_1の予約受付処理発生フラグを解除してOFF状態にする。
次に、電文処理要求受付部A3_2において、空席照会の電文処理要求を受け付ける処理フローは上記の予約受付の電文処理要求を受けた場合(電文処理要求受付部A3_1)と一部を除き同様である。
すなわち、受付スレッドa3_4の発生フラグ設定a3_11処理が、空席照会電文が発生したことを示す発生フラグを空席照会処理発生フラグ30_2に設定することと、空席照会処理待受スレッドa3_5が空席照会の電文処理部A4_2(図5参照)へ処理対象の電文があることを通知(イベントc4_2)することを除き、上記の予約受付の電文処理要求を受け付ける処理と同様の処理フローとなる。また、受付スレッドa3_6が、空席照会処理発生フラグ30_2がON状態の時に電文処理要求c3_21を受けたため、空席照会処理待受スレッドa3_5を起動しないことを示している点も同様である。
このようにして、図8及び図9にそれぞれ示した電文処理要求部A2及び電文処理要求受付部A3は、それぞれ、該電文処理要求を受けると、対応する電文処理要求が発生したことを示す電文発生フラグ、及び電文の処理要求が発生したことを示す処理発生フラグがOFF状態であることを各々が確認した上で該電文発生フラグ、及び該処理発生フラグをON状態に設定し予め定められた時間まで待受処理を行い、各々が集約した電文処理要求をそれぞれ該電文処理要求受付部及び該電文処理部へ送って処理対象の電文が発生したことを通知すると共に、両フラグをOFF状態に戻す。
従って、各々の待受処理の多重起動を避けることができ、更に多くのクライアントやイベント数の増加に容易に対応できると共に、処理件数当たりのファイルやデータベースへのアクセス回数は更に少なくなり、アクセス効率が向上する。
次に、図1及び5に示した各電文処理部A4_1、A4_2の実施例を図10に示した処理フローブロック図を参照して説明する。なお、本実施例では電文種別毎処理装置3に属するものとして、図5のシステム構成例に示したように、予約受付処理装置3_1と空席照会処理装置3_2の二つを挙げており、電文処理部A4_1は予約受付の電文処理部、電文処理部A4_2は空席照会の電文処理部にそれぞれ対応している。
まず、電文処理部A4_1は、電文処理要求受付部A3_1から状況確認要求や結果取得要求などの処理要求c4_1を受けると、未処理予約受付電文一括読出a4_11を行い、入力電文記憶装置4から未処理の予約受付電文を一括して読み出す(アクセスd3_r)。なお、その電文が処理済であるか否かは、各電文処理部A4が電文処理後に入力電文記憶装置4の処理状態を更新するなどによって知ることができる。
続いて、電文処理部A4_1は、予約情報読出a4_12で管理情報記憶装置6の予約情報を参照し(アクセスd4_r)、予約結果登録a4_13でそれを更新(アクセスd4_w)して電文の処理を行う。次に、その処理結果を電文処理結果登録a4_14で処理結果記憶装置5に格納(アクセスd5_w)し、次の電文処理状態更新a4_15で入力電文記憶装置4の対応する処理状態を更新(アクセスd3_w)して一連の処理フローを終了する。
次に、電文処理部A4_2が、電文処理要求受付部A3_2から処理要求c4_2を受けると、未処理空席照会電文一括読出a4_21を実行して入力電文記憶装置4から未処理の空席照会電文を一括して読み出す(アクセスd3_r)。続いて、空席情報読出a4_22で管理情報記憶装置6の空席情報を参照(アクセスd4_r)し、その処理結果を電文処理結果登録a4_23で処理結果記憶装置5に格納(アクセスd5_w)する。次に電文処理状態更新a4_24で入力電文記憶装置4の対応する処理状態を更新(アクセスd3_w)して一連の処理を終了する。
このようにして、電文処理部A4は、段階的に集約された電文処理要求を受けて、入力電文記憶装置4に格納されている未処理の電文を一括して読み出すと共に、管理情報記憶装置6から各電文の処理に必要な情報を参照・更新して、各電文データを処理し、それらの処理結果を処理結果記憶装置5に一括して格納し、更に入力電文記憶装置4の対応する電文を、処理済として更新する。
従って、電文受付部A1はクライアントからの状況確認要求や結果取得要求に応じて、入力電文記憶装置4と処理結果記憶装置5から一括して読み出して要求元のクライアントに応答できる。
以上のように、本発明に係る電文処理装置は、複数のクライアントから同時多発する大量の電文を集約して処理するので、ファイルやデータベースへのアクセス回数が極少化され、アクセス効率が向上し、電文を効率的に処理することができる。
従って、その並列処理によるデ一タ参照・更新のためのアクセス競合がボトルネックとはならず、その多重分散処理の効果が容易に得られる。
また、そのアクセス競合を回避するための参照・更新を行うファイルやデータベースの複製を多数設ける必要がないので、それらを自動的に同期化させるような複雑なシステム構成を採ることなく、経済的にスケーラビリティを確保した電文処理装置を実現することができる。
また、実施例のように電文種別毎に集約することは必須ではなく、対応する電文処理部の例えば処理機能別毎・処理内容別毎に段階的に集約してもその効果に変わりはない。
また、段階的に電文処理要求を集約することは、三次集約に限定されず、電文処理装置の要件に合わせて任意に集約規模を拡大縮小することでコストパフォーマンスを最適化することも可能である。
また、本発明に係る電文処理装置は、本実施例で示したチケット予約システムのみならず、WEBや金融・流通のオンライン処理、大規模ネットワークのオペレーションシステム等、多数のクライアントから同時に発生する処理要求やイベント通知等の電文をリアルタイムに処理する電文処理システムに適用できる。
本発明に係る電文処理装置の原理(システム構成)を示すブロック図である。 本発明に係る電文処理装置の原理(電文受付部)を示すブロック図である。 本発明に係る電文処理装置の原理(電文処理要求部/電文処理要求受付部)を示すブロック図である。 本発明に係る電文処理装置の原理(電文処理部)を示すブロック図である。 本発明に係る電文処理装置の実施例(チケット予約システム構成)を示すブロック図である。 本発明に係る電文処理装置の実施例(電文受付部の1/2)を示すブロック図である。 本発明に係る電文処理装置の実施例(電文受付部の2/2)を示すブロック図である。 本発明に係る電文処理装置の実施例(電文処理要求部)を示すブロック図である。 本発明に係る電文処理装置の実施例(電文処理要求受付部)を示すブロック図である。 本発明に係る電文処理装置の実施例(電文処理部)を示すブロック図である。
符号の説明
1、1_11〜1_n3 クライアント
2、2_1、2_2 クライアント接続装置
3 電文種別毎処理装置
3_1 電文種別1処理装置、予約受付処理装置
3_2 電文種別2処理装置、空席照会処理装置
4 入力電文記憶装置
5 処理結果記憶装置
6 管理情報記憶装置
10_1 予約受付電文一次保存領域
10_2 空席照会電文一次保存領域
20_1 予約受付電文発生フラグ
20_2 空席照会電文発生フラグ
30_1 予約受付処理発生フラグ
30_2 空席照会処理発生フラグ
A1、A1_1〜A1_n 電文受付部
A2 電文処理要求部
A3、A3_1、A3_2 電文処理要求受付部
A4_1、A4_2 電文処理部
a1_1 クライアント応答スレッド
a1_2、a2_2 予約受付待受スレッド
a1_3、a2_5 空席照会待受スレッド
a2_1、a2_3、a2_4、a2_6、a3_1、a3_3、a3_4、a3_6 受付スレッド
a3_2 予約受付処理待受スレッド
a3_5 空席照会処理待受スレッド
a4_11 未処理予約受付電文一括読出
a4_12、a4_22 予約情報読出
a4_13、予約結果登録
a4_14、a4_23 電文処理結果登録
a4_15、a4_24 電文処理状態更新
a4_21 未処理空席照会受付電文一括読出
c1、c2、c3、c4 イベント(_1、_2などを付加した符号もある。)
d1、d2、d3、d4、d5 アクセス(_1、_2、_r、_wを付加した符号もある。)
図中、同一符号は同一又は相当部分を示す。

Claims (8)

  1. 複数のクライアントから同時に電文及びその電文処理要求を受け付けて該電文処理要求を集約すると共に、該電文処理要求に係る電文を、入力電文記憶装置に一括格納する第1手段と、
    該第1手段で集約した電文処理要求を受けて更に一回以上集約すると共に、該集約した電文処理要求に基づき該電文処理要求に対応した電文を、該入力電文記憶装置から一括して読み出して対応した処理を行う第2手段と
    を備え、
    クライアントからの電文処理要求を受付けた時に通知した通番により、クライアントから電文処理状態や電文処理結果を随時、照会可能としたことを特徴とした電文処理装置。
  2. 複数のクライアントから同時に電文処理要求を受け付けて該電文処理要求を電文種別毎に一次集約すると共に該電文処理要求に係る電文を入力電文記憶装置に電文種別毎に一括格納する複数の電文受付部、及び該一次集約した電文処理要求を受けて、該電文種別毎に更に二次集約する電文処理要求部を、各々が含む複数のクライアント接続装置と、
    該電文処理要求に基づき各クライアント接続装置で生成された電文処理要求を受けて、それらを更に該電文種別毎に三次集約する電文処理要求受付部、及び該電文処理要求受付部から該三次集約した電文処理要求を受けて、該電文処理要求に対応した電文データを、該入力電文記憶装置から一括して読み出し該電文種別に対応した処理を行う電文処理部を、各々が含む複数の電文種別毎処理装置と、
    を備えたことを特徴とした電文処理装置。
  3. 請求の範囲2において、
    該電文受付部が、該クライアントから新規に要求された電文及びその電文処理要求に通番を付加する通番処理と、予め定めた件数又は予め定めた時間になるまで該電文を一旦保存し、該件数又は該時間に達した時、それまで保存した電文を該通番と共に該入力電文記憶装置に一括して書き込み、要求元のクライアントには該通番を通知することを特徴とした電文処理装置。
  4. 請求の範囲3において、
    該電文受付部が、各クライアントから該通番を用いた電文種別毎の確認要求を受けた時、該入力電文記憶装置から該通番に対応する電文処理状態を読み出して該クライアントに応答することを特徴とした電文処理装置。
  5. 請求の範囲2において、
    該電文処理要求部及び該電文処理要求受付部が、それぞれ、該電文処理要求を受けて、それぞれに予め定められた時間まで待受処理を行うことにより各集約を行い、各々が集約した電文処理要求をそれぞれ該電文処理要求受付部及び該電文処理部へ送って処理対象の電文が発生したことを通知することを特徴とした電文処理装置。
  6. 請求の範囲5において、
    該電文処理要求部及び該電文処理要求受付部が、それぞれ、該電文処理要求を受けると、対応する電文処理要求が発生したことを示す電文発生フラグ、及び電文の処理要求が発生したことを示す処理発生フラグがOFF状態であることを各々が確認したときのみ該電文発生フラグ、及び該処理発生フラグをON状態に設定し予め定められた時間まで該待受処理を行い、各々が集約した電文処理要求をそれぞれ該電文処理要求受付部及び該電文処理部へ送って処理対象の電文が発生したことを通知すると共に、両フラグをOFF状態に戻すことを特徴とした電文処理装置。
  7. 請求の範囲4において、
    該電文処理部が、該電文処理要求を受けて、該入力電文記憶装置に格納されている未処理の電文を一括して読み出すと共に、管理情報記憶装置から各電文の処理に必要な情報を参照・更新をして、各電文を処理し、それらの処理結果を処理結果記憶装置に一括して格納し、更に該入力電文記憶装置中の対応する電文を、処理済として更新することを特徴とした電文処理装置。
  8. 請求の範囲7において、
    該電文受付部が、各クライアントから電文種別毎の結果取得要求を受けた時、該処理結果記憶装置から処理結果を読み出して該クライアントに応答することを特徴とした電文処理装置。
JP2007500371A 2005-01-26 2005-01-26 電文処理装置 Pending JPWO2006080058A1 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2005/001014 WO2006080058A1 (ja) 2005-01-26 2005-01-26 電文処理装置

Publications (1)

Publication Number Publication Date
JPWO2006080058A1 true JPWO2006080058A1 (ja) 2008-06-19

Family

ID=36740093

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007500371A Pending JPWO2006080058A1 (ja) 2005-01-26 2005-01-26 電文処理装置

Country Status (2)

Country Link
JP (1) JPWO2006080058A1 (ja)
WO (1) WO2006080058A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5834998B2 (ja) * 2012-02-23 2015-12-24 富士通株式会社 イベント処理方法、イベント収集方法、イベント処理プログラム、イベント収集プログラム及び情報処理装置

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH03105544A (ja) * 1989-09-20 1991-05-02 Hitachi Ltd オンライントランザクション処理システム

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2667818B2 (ja) * 1986-10-09 1997-10-27 株式会社日立製作所 トランザクション処理方法
JPH01291356A (ja) * 1988-05-18 1989-11-22 Nec Corp メッセージデータのバッチ入力によるオンライントランザクション処理方式
JPH0973432A (ja) * 1995-09-08 1997-03-18 Hitachi Ltd オンライントランザクション高速処理方式

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH03105544A (ja) * 1989-09-20 1991-05-02 Hitachi Ltd オンライントランザクション処理システム

Also Published As

Publication number Publication date
WO2006080058A1 (ja) 2006-08-03

Similar Documents

Publication Publication Date Title
CN102037463B (zh) 使用全局确认的提交进行分布式事务的基于日志的复制
US7900085B2 (en) Backup coordinator for distributed transactions
CN110968586B (zh) 分布式事务处理方法及装置
JP6225262B2 (ja) 分散データグリッドにおいてデータを同期させるためにパーティションレベルジャーナリングをサポートするためのシステムおよび方法
CN114363407B (zh) 消息服务方法及装置、可读存储介质及电子设备
JP5686034B2 (ja) クラスタシステム、同期制御方法、サーバ装置および同期制御プログラム
CN101146127B (zh) 一种分布式系统中客户端缓存更新的方法和装置
US20120278817A1 (en) Event distribution pattern for use with a distributed data grid
CN103870570A (zh) 一种基于远程日志备份的HBase数据可用性及持久性的方法
CN109901948B (zh) 无共享数据库集群异地双活容灾系统
US20230110826A1 (en) Log execution method and apparatus, computer device and storage medium
CN103634411A (zh) 一种具有状态一致性的市场数据实时广播系统及方法
CN113360577A (zh) 一种mpp数据库数据处理方法、装置、设备及存储介质
CN107562803B (zh) 数据供应系统及方法、终端
CN111752892B (zh) 分布式文件系统及其实现方法、管理系统、设备及介质
JPWO2006080058A1 (ja) 電文処理装置
JP5494915B2 (ja) レプリケーションシステム、マスタサーバ、レプリカサーバ、レプリケーション方法、及びプログラム
CN116055499A (zh) 基于redis的集群任务智能化调度方法、设备、介质
CN105760215A (zh) 基于映射规约模型分布式文件系统作业的运行方法
JP2007265043A (ja) スケジューラプログラム、サーバシステム、スケジューラ装置
CN110647298B (zh) 一种数据存储控制方法及装置
CN113190624A (zh) 基于分布式跨容器的异步转同步调用方法及装置
CN114003180A (zh) 一种基于跨机房Hadoop集群的数据处理方法及装置
JPH11312112A (ja) データベース複製機能を持つ計算機システム
CN115357342B (zh) 冷启动资源处理方法及装置

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20091201

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20100406