JP2007226584A - Transaction system - Google Patents
Transaction system Download PDFInfo
- Publication number
- JP2007226584A JP2007226584A JP2006047667A JP2006047667A JP2007226584A JP 2007226584 A JP2007226584 A JP 2007226584A JP 2006047667 A JP2006047667 A JP 2006047667A JP 2006047667 A JP2006047667 A JP 2006047667A JP 2007226584 A JP2007226584 A JP 2007226584A
- Authority
- JP
- Japan
- Prior art keywords
- processing
- request
- information
- transaction
- requirement
- 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.)
- Granted
Links
Images
Abstract
Description
本発明は、株式等の有価証券を含む商品の取引を含む所定の業務を実現するための技術に関する。その中でも取引、特にいわゆる証券市場と称される取引所で用いられる証券取引システム、その方法およびそのためのプログラムに関する。 The present invention relates to a technique for realizing a predetermined operation including a transaction of a product including securities such as stocks. Among them, the present invention relates to trading, in particular, a securities trading system used in an exchange called a securities market, a method thereof, and a program therefor.
従来、証券取引などの業務を実行する場合、複数の処理装置を連携して業務を実現することが実行されている。このような処理を実行するために、いわゆるキューを用いて処理が行われている。例えば、特許文献1においては、以下の構成が開示されている。業務 プロセス トラッキング装置に関し,異なる業務 システム間を跨いで行われる複数のアプリケーションからなる業務 プロセス の流れを,既存システムを変更することなく追跡することを可能とすることを目的とする。この目的を達成するために、特許文献1では、イベント管理装置1は,各業務 システムA3〜C5のイベント抽出部32〜52がイベント抽出定義に基づいて抽出したイベントデータを収集し,イベントキュー 12にキュー イングする。イベント関連付け部13は,イベントデータを業務 データ単位にまとめ,業務 データ間の関連付けを行ってイベント管理DB14に蓄積する。ユーザ端末6から検索条件が入力されると,出力部16が検索条件に従ってイベント管理DB14を検索し,業務 データ間の関連をツリー形式でユーザ端末6に出力し表示する。
2. Description of the Related Art Conventionally, when executing a business such as a stock transaction, it has been executed to realize a business by linking a plurality of processing devices. In order to execute such processing, processing is performed using a so-called queue. For example,
しかしながら、特許文献1においては、ワークフローを対象としており、業務プロセスを如何にして把握(追跡)するかを目的としている。すなわち、特許文献1では、各処理装置が実行すべき処理が行われていない場合、どのようにリカバリー(回復)させるかに関しては、特に考慮されていない。このため、特許文献1においては、処理装置での処理がとまった場合、所定の業務を効率的に回復させることができなかった。特に、ある装置から処理依頼(時限式の所定時間などでその効力が消滅するもの)を発行して、それをトリガーに処理を実行するものの場合、未処理の案件が蓄積されてしまうとの問題が生じる。さらに、このように未処理の案件が蓄積されると、記憶装置などのハードウエア資源が無駄になるばかりでなく、ひいてはこれらハードウエア資源を含むシステムが停止し、取引を含む業務自体が中止されることも生じてしまう。
However,
そこで、本発明では、自身に対する処理依頼に関する情報がなく、実態としては処理すべきもの(案件、要件情報)が存在する場合には、自身に対して依頼情報を発行して処理を開始する。ここで、本発明においては、処理依頼に関する情報とこれに対応し、処理を実行するために必要な要件情報を別に扱うことも含まれ、この要件情報の有無により実体として処理すべきものが存在するかを判断してもよい。 Therefore, in the present invention, when there is no information related to the processing request for itself and there is actually an item to be processed (case, requirement information), the request information is issued to itself and the processing is started. Here, in the present invention, the information regarding the processing request and the corresponding requirement information necessary for executing the processing are included separately, and there is what should be processed as an entity depending on the presence or absence of the requirement information. It may be judged.
より具体的には、本発明は以下のように構成される。
それぞれが複数のグループのいずれかに属する複数の取引端末であって、取引要求を送信する取引端末と接続され、複数の処理装置から構成され前記取引要求に応じた証券取引処理を行う取引システムにおいて、前記複数の処理装置は、少なくとも前記証券取引処理の一部を実行するための処理依頼であって発行後に効力が消滅することがある処理依頼を発行する第1の処理装置および前記依頼情報に応じた処理を実行する第2の処理装置を含み、前記第1の処理装置が、前記処理依頼を発行し、前記処理依頼に対応する前記処理依頼で実行すべき処理を実行するための要件情報を要件データベースに格納し、前記第2の処理装置が、発行された処理依頼の有無を確認し、(1)前記処理依頼がある場合には、対応する要件情報を前記要件データベースから検索して、対応する処理を実行し、(2)前記処理依頼がない場合には、前記要件データベースを検索して、自身で実行すべき処理のうち、未処理の要件情報を検索し、未処理の要件情報がある場合には、自身に対して未処理の要件情報の存在に対応する依頼情報を発行し、前記依頼情報を受けて前記要件データベースから、対応する要件情報を取得して、該当する処理を実行する。ここで、発行後一定期間後に効力が消滅する処理依頼とは、マシンの障害時等に回復されない、非永続的なメッセージを含む。また、一定期間後に効力もしくは自身が消滅するものでもよい。
More specifically, the present invention is configured as follows.
In a transaction system, each of which is a plurality of transaction terminals belonging to any of a plurality of groups, connected to a transaction terminal that transmits a transaction request, and configured from a plurality of processing devices to perform a securities transaction process corresponding to the transaction request The plurality of processing devices include a first processing device that issues a processing request for executing at least a part of the securities transaction processing and that may become ineffective after issuance, and the request information. Requirement information for executing a process to be executed by the process request corresponding to the process request by issuing the process request, including a second processing apparatus that executes a process according to the request Is stored in the requirement database, and the second processing device checks whether there is an issued processing request. (1) If there is the processing request, the corresponding requirement information is stored in the requirement data. (2) If there is no processing request, search the requirement database and search for unprocessed requirement information among the processing to be executed by itself. If there is unprocessed requirement information, it issues request information corresponding to the existence of unprocessed requirement information to itself, receives the request information, and acquires the corresponding requirement information from the requirement database. The corresponding process is executed. Here, the processing request whose effect disappears after a certain period after issuance includes a non-permanent message that is not recovered in the event of a machine failure or the like. Further, it may be effective or disappear after a certain period.
ここで、発行された処理依頼の有無の確認は、有効な処理依頼の有無を確認することも含む。例えば、発行された処理依頼が無効化(効力の消滅および自身の消滅を含む例えば、タイムアウト)されることを検知することも含まれる。また、第1の処理装置は、この処理依頼を所定のデータベース(各処理装置からアクセス可能な)に書き込む。なお、このデータベースは、要件データベースとしてもよい。また、第2の処理装置の処理依頼の有無の確認は、上記のデータベースにアクセスことで実行する。この際、要件情報に処理・未処理を示すフラグを設け、この内容を用いて有無の確認を実行してもよい。但し、処理依頼を第2の処理装置に送信し、要件情報を要件データベースに格納する構成にしてもよい。 Here, the confirmation of the presence / absence of the issued processing request includes the confirmation of the presence / absence of a valid processing request. For example, it also includes detecting that an issued processing request is invalidated (for example, time-out including disappearance of effectiveness and disappearance of itself). Further, the first processing device writes this processing request in a predetermined database (accessible from each processing device). This database may be a requirement database. Further, the confirmation of the presence or absence of a processing request from the second processing apparatus is executed by accessing the database. At this time, a flag indicating processing / non-processing may be provided in the requirement information, and the presence / absence confirmation may be executed using this content. However, the processing request may be transmitted to the second processing apparatus, and the requirement information may be stored in the requirement database.
また、第2の処理装置が発行する依頼情報は、「擬似」処理依頼としてよい。つまり、内容的に、処理依頼と同じ項目とし、対象の要件情報(処理対象)を要件データベースに格納された要件情報に従って入力する。つまり、要件データベースに格納された要件情報のうち、自身で処理すべきものであって、未処理の要件情報を抽出し、その要件情報に対応する識別情報を書き込む。ここで、タイムスタンプ機能を用いて順序性を保つよう構成してもよい。つまり、抽出された要件情報には、タイムスタンプ機能により記録された依頼時を示す情報が含まれており、これを用いて順序性を保つように制御する。 The request information issued by the second processing apparatus may be a “pseudo” processing request. That is, the content is the same item as the processing request, and the target requirement information (processing target) is input according to the requirement information stored in the requirement database. That is, out of the requirement information stored in the requirement database that should be processed by itself, unprocessed requirement information is extracted, and identification information corresponding to the requirement information is written. Here, the time stamp function may be used to maintain the order. In other words, the extracted requirement information includes information indicating the request time recorded by the time stamp function, and the order information is controlled using this information.
さらに、依頼情報は、タイムアウトした(無効化)ことを検知した場合に、発行することも本発明に含まれる。 Further, the present invention includes issuing the request information when it is detected that time-out (invalidation) has been detected.
また、上記において、以下の処理を実行することも本発明に含まれる。前記第2の処理装置は、前記未処理の処理依頼がある場合(例えば、タイムアウト等の無効化を検出した場合)、当該未処理の要件情報の件数を計数して、前記該当する処理を実行した場合もしくは前記対応する要件情報を取得した場合、前記件数を1減算して、この件数が0を示すまで自身への依頼情報の発行を繰り返すことを可能とする。 In the above, the following processing is also included in the present invention. When there is an unprocessed processing request (for example, when invalidation such as a timeout is detected), the second processing device counts the number of the unprocessed requirement information and executes the corresponding processing When the corresponding requirement information is acquired, the number of cases is decremented by 1, and the request information issuance to itself can be repeated until the number of cases indicates 0.
ここで、件数の計数は、以下のとおりとしてもよい。まず、要件情報に自身が処理済みか未処理かを示す情報を含ませておき、このうち未処理の要件情報であって、自身が処理すべきものを識別情報等により計数する。より具体的には、以下のとおりとする。「グループコード」を検索条件とする場合はそのプロセスが担当する「グループコード(当該グループを識別する識別子)」での集計,「キー」を検索条件とする場合はそのプロセスが担当する「グループコード」を検索条件として「キー」単位での集計を行って,再送用MQ(依頼情報)にその件数を設定する。(「キー」の場合は,MQは未処理要件があるキーの種類分,送信する)。ここで、未処理の件数を要件データベースの内容から計数しておき、これを記録しておいてもよい(つまり、この記録内容を未処理の件数とする)。 Here, the number of cases may be as follows. First, information indicating whether or not it has been processed is included in the requirement information, and unprocessed requirement information that should be processed by itself is counted using identification information or the like. More specifically, it is as follows. If "group code" is used as the search condition, the total is calculated using the "group code (identifier that identifies the group)" assigned to the process. "Is used as a search condition, and is aggregated in units of" keys ", and the number of cases is set in the retransmission MQ (request information). (In the case of “key”, the MQ sends for the key types that have unprocessed requirements). Here, the number of unprocessed cases may be counted from the contents of the requirement database and recorded (that is, the recorded contents are regarded as the number of unprocessed cases).
また、要件情報としては、処理済みのものを消去し、未処理のものを要件データベースに残す構成として、残った要件情報の件数をカウントすることで実現することが可能になる。 The requirement information can be realized by counting the number of remaining requirement information as a configuration in which processed information is deleted and unprocessed information is left in the requirement database.
また、上記の構成において、前記処理依頼および前記依頼情報の少なくとも一方は、一定時間後に自身の効力が消滅(無効化、タイムアウト)する情報であることも本発明に含まれる。また、前記処理依頼および前記依頼情報は、転送キューであってもよい。 Further, in the above configuration, the present invention also includes that at least one of the processing request and the request information is information whose own effect disappears (invalidation, timeout) after a predetermined time. Further, the processing request and the request information may be a transfer queue.
さらに、本発明では、いわゆるトランザクション(複数の取引要求)を、所定の単位で分割してそれぞれ各処理(処理のためのサブ業務単位を含む)を並行処理で実行するように構成したものに適用することも含まれる。 Furthermore, the present invention is applied to a configuration in which a so-called transaction (a plurality of transaction requests) is divided into predetermined units and each processing (including sub-operation units for processing) is executed in parallel processing. To include.
本発明によれば、処理の回復をより容易に実現することが可能になる。 According to the present invention, it is possible to more easily realize processing recovery.
本発明の実施の形態について、図面を用いて説明する。本実施の形態は、証券(株式)の取引を例に説明するが、本発明はそれに限定されるものではない(他業務などに適用することも本発明に含まれる)。 Embodiments of the present invention will be described with reference to the drawings. In the present embodiment, a transaction of securities (stocks) will be described as an example. However, the present invention is not limited to this (application to other business operations is also included in the present invention).
まず、本実施の形態の基本的な内容について説明する。
(1)通常は、連絡元プロセス(例えば、図1や2の受付装置2)から連絡先プロセス(例えば、図1,2の取引処理装置3)図に対して、処理依頼(例:MQ「転送キュー」)を送信する。ここでは、送り先を装置すなわちハードウエアとしたが、本実施の形態では、ハードは異なる場合もあれば同一の場合も含む。あくまでも、あるプロセス(処理プログラム)から,処理依頼先のプロセスに,要件データベースの登録と処理依頼(MQ)を送信できればよい。例えば、「注文受付」というプロセスは端末グループ数分あり,「取引処理制御1」というプロセスは銘柄グループ数分動作している。「取引処理制御1」は複数の銘柄キーの集合である「銘柄グループ」に括り付いている。「取引処理制御1」という機能名称と,銘柄グループの組合せで1つのプロセスが特定される。サーバとグループが1対1でもよいし、サーバに複数のグループが配置されていてもよい。
(2)連絡先プロセスでは,MQを受信すると,当該MQに対応する要件DBから要件情報(レコード)を1件取得(SELECT)する。ここで、この取得の方法としては、(a)自身の「グループ」(もしくは自身)を識別する識別子(例えば、グループコード)を用いて行う(MQと要件情報には、それぞれグループコードを含ませるようにする)、(b)取引対象の銘柄を識別する識別子を用いて行う(MQと要件情報には、それぞれ銘柄を識別する識別子を含ませるようにする)。また、要件情報には、連絡元プロセスが処理依頼を発行(もしくは送信など所定の処理であり、要件情報に対する処理であってもよい)を実行した時間の時間情報を、タイムスタンプ機能を用いて含ませておく。そして、この時間情報の順に従って、取得する順序を決定する。例えば、古い順に取得するようにする。
First, the basic contents of this embodiment will be described.
(1) Normally, from a contact source process (for example, the accepting
(2) Upon receiving the MQ, the contact process acquires one requirement information (record) from the requirement DB corresponding to the MQ (SELECT). Here, this acquisition method is performed by using an identifier (for example, a group code) for identifying (a) its own “group” (or itself) (MQ and requirement information each include a group code) And (b) using an identifier for identifying a brand to be traded (MQ and requirement information include an identifier for identifying a brand, respectively). The requirement information includes time information of the time when the contact source process issued a processing request (or is a predetermined process such as transmission and may be a process for the requirement information) using a time stamp function. Include it. Then, the order of acquisition is determined according to the order of the time information. For example, acquisition is performed in order of oldness.
ここで、MQが無効(タイムアウト)になるなどして無効化した場合(もしくは無効化を検出した場合)、連絡先プロセスでは、要件データベースを検索して、未処理の案件(例えば、要件情報)がないかを検知する。この検知は、上記(2)に記載した方法と同様に検索等を行う。より詳細には、以下のとおりである。要件データベースと処理依頼(MQ)双方に,処理依頼先の「グループコード」および「キー」を付与している。連絡先プロセスは,MQGETでメッセージ(MQ)を取得すると,自プロセスむけのメッセージであることをチェックしてから「グループコード」または「キー」が同一,かつ未処理であることを検索条件として,登録時刻の最も古い要件レコードを要件データベースから検索する。 Here, when MQ is invalidated (timeout), etc. (or when invalidation is detected), the contact process searches the requirements database and issues (for example, requirement information) Detect if there is any. In this detection, a search or the like is performed in the same manner as the method described in (2) above. In more detail, it is as follows. The “group code” and “key” of the processing request destination are assigned to both the requirement database and the processing request (MQ). When the contact process acquires a message (MQ) with MQGET, it checks that it is a message for its own process, and then uses the same "group code" or "key" and is unprocessed as a search condition. The requirement record with the oldest registration time is searched from the requirement database.
なお、MQは要件データベースを検索するためのトリガーである。すなわち、MQには,「何を行うか」という情報が示されていなくともよい。「何を行うか」は,要件データベース(の要件情報)に登録されている。要件データベースには,「何を行うか」として例えば対応する注文データ(注文受信データベースなどに記録)などを特定する情報が設定されているので,要件データベースを取得する順序で注文受信データベースの処理を行うことが可能になる(例;取引所で必要な同一銘柄内での注文の処理順序性を確保している)。 MQ is a trigger for searching the requirement database. That is, the MQ does not have to indicate information “what to do”. “What to do” is registered in the requirements database. In the requirement database, for example, information specifying the corresponding order data (recorded in the order reception database, etc.) is set as “what to do”, so the order reception database is processed in the order in which the requirement database is acquired. (E.g., ensuring the order of order processing within the same stock required by the exchange).
(3)次に、連絡先プロセスでは、取得した要件情報に対応する処理を実行するプログラムを起動し、処理を実行する。そして、次プロセス(例えば、約定処理装置)への通知を行う。 (3) Next, in the contact address process, a program for executing the process corresponding to the acquired requirement information is started and the process is executed. And it notifies to the next process (for example, contract processing device).
次に、本実施の形態におけるシステム構成図を図1に示す。各コンピュータは、ネットワークを介して互いに接続されている。また、各コンピュータは、メモリ、ハードディスクを含む記憶装置、CPUなどの処理装置を有し、記憶装置に格納されたプログラムに従って、処理装置が情報処理を実行するものである。図1に示すように、本実施の形態におけるシステムは、取引端末1、受付装置2、取引処理装置3、約定処理装置4と、取引に関する情報が格納された記憶装置群5から構成される。これら構成要件のそれぞれは、複数から構成されるものであるが、(1)取引端末1はグループとして複数の取引端末をまとめておいてもよい、(2)また、受付装置2、取引処理装置3、約定処理装置4は、ハードウエアとして一体のサーバ装置として構成され、それぞれはその機能を有するソフトウエアとして構成してもよい。また、(2)の場合、受付装置2、取引処理装置3を一体、取引処理装置3、約定処理装置4を一体などとしてもよい。本実施の形態では、図2に示すように約定処理装置4と取引処理装置3を一体とした例で説明する。この図1,2の構成では、各受付装置2(21,22)は、取引端末のグループ毎(証券会社など)に対応付けられている。また、各取引処理装置3、各約定処理装置4は(もしくはこれらが一体化された処理装置31,32)、処理すべき銘柄毎に対応付けられており、この対応関係の取引要求についての処理を実行する。この対応関係は、装置すなわちハードウエアでなく、ソフトウエアが有するようにしてもよい。さらに、この対応関係は、取引量などの条件に基づいて動的に変更してもよい。すなわち、あるグループからの取引要求やある銘柄の取引要求が(増加して)所定数(量)になった場合、所定の装置(例えば、取引要求の最も少ない同じ種類の装置、コンピュータ資源)をそのグループ(もしくは銘柄)の処理を実行するようにしてもよい。また、同じ種類の装置において、取引要求(もしくはそれに伴う計算量)の関係が一定の関係(差分が閾値以上や1:10などの所定の関係)を満たすかを検知して、この内容に応じて対応関係を変更する(少ない取引要求の装置を多い取引要求の装置に変える)ことも、本実施の形態に含まれる。このように、分散化処理と組み合わせることで以下の効果を達成することが可能になる。
(1)業務要件である「処理順序性保証」をすることが可能となる。「端末グループ:n→銘柄グループ:m→端末グループ:n」のような流れで、サブ業務を分割しているため、処理順序性確保が問題となりますが、要件DB内の一番古い未処理のものから順に処理するため、処理順序性保証(銘柄グループ単位)が可能になる(銘柄グループ1の要件DBに対して、n個の端末グループから処理要求が発生する)。
(2)障害復旧対象リソースをDBMSのみとすることが可能になる。トランザクションモニタと、DBMSの両方で、回復対象リソースを持ったXA連携(2相コミット)では、Commit処理性能が長くなるため、回復対象リソースをDBMSのみとし、非XA連携としcommit性能を確保することが可能になる。なお、本発明は、XA連携した場合でも適用可能であることは言うまでもない。
(3)回復時の順序性確保が可能になる。(1)の機能(要件データベース内の一番古い未処理のものから順に処理する)により、障害回復後も、順序性を確保することが可能になる。
なお、サブ業務単位に分散化しないことも本発明に含まれる。
Next, FIG. 1 shows a system configuration diagram according to the present embodiment. Each computer is connected to each other via a network. Each computer has a processing device such as a memory, a storage device including a hard disk, and a CPU, and the processing device executes information processing according to a program stored in the storage device. As shown in FIG. 1, the system in the present embodiment includes a
(1) “Processing order guarantee”, which is a business requirement, can be performed. Since the sub-tasks are divided in a flow like “terminal group: n → stock group: m → terminal group: n”, securing the processing order is a problem, but the oldest unprocessed in the requirement DB Therefore, the processing order is guaranteed (stock group unit) (processing requests are generated from n terminal groups for the requirement DB of the brand group 1).
(2) It becomes possible to use only the DBMS as the failure recovery target resource. In XA linkage (two-phase commit) with recovery target resources in both the transaction monitor and the DBMS, the commit processing performance becomes long, so the recovery target resource is only the DBMS and non-XA linkage is used to ensure commit performance. Is possible. Needless to say, the present invention is applicable even in the case of XA cooperation.
(3) It is possible to ensure the order during recovery. With the function (1) (processing is performed in order from the oldest unprocessed one in the requirement database), it is possible to ensure the order even after failure recovery.
It should be noted that the present invention also includes not being distributed to sub-business units.
次に、図3を用いて本実施の形態の処理フローについて、説明する。まず、初期処理として、ステップ100で、プロセスを起動する。以下のステップも含みここでは、取引処理装置3での処理を例に説明する。例えば、本装置で用いるプログラムを起動させる。
Next, the processing flow of the present embodiment will be described with reference to FIG. First, as an initial process, in step 100, a process is started. Here, including the following steps, processing in the
次に、ステップ101において、MQGET、すなわち、処理依頼を取得する。MQは、受付装置2から送信されたもので、所定の記憶装置に格納されている。そして、MQ記憶装置に存在しない場合には、MQGETの動作がタイムアウトとなる。ここで、MQは予め定めた時間になるとタイムアウトと称して無効化するように制御してもよい。この予め定めた時間としては、プロセスの起動の際は、それ以外の場合に比べて短い時間でタイムアウトになるよう設定してもよい。このように設定することにより、系切替などによって格納されているMQが消滅することを防止することが可能になる。なお、起動の際とは、起動してから最初に記憶装置にアクセスすることを含む。
Next, in
次に、ステップ102において、MQGET(もしくはMQ)がタイムアウトになったかを検知する。タイムアウトになった場合(検知した場合)は、ステップ103に進み、自身に対するMQ送信を行う。なお、ここで、MQは、要件データベースを検索するためのトリガーであればよく。「何を行うか」という情報が示されていなくともよい。「何を行うか」は,要件データベース(の要件情報)に登録されている。要件データベースには,「何を行うか」として例えば対応する注文データ(注文受信データベースなどに記録)などを特定する情報が設定されている。このように、トリガーとなるもの(かつ所定の条件で無効化されるものならより好適である)であればよく、MQ以外のものであっても構わない。
Next, in
ここで、ステップ103の詳細について、図4を用いて説明する。
まず、ステップ1031において、図5に示す要件データベースから未処理の案件(すなわち要件情報)の数を計数する。すなわち、各要件情報のうち、処理済フラグが未処理を示すものを抽出し、そのうち当該取引処理装置が処理すべきことを示す情報(当該取引処理装置の識別情報でもよい)の要件情報の数を計数する。なお、まず、当該取引処理装置が処理すべきことを示す情報(当該取引処理装置の識別情報でもよい)の要件情報を抽出し、その中から処理済みフラグが未処理を示すものを検知してもよい。
Details of
First, in step 1031, the number of unprocessed matters (that is, requirement information) is counted from the requirement database shown in FIG. That is, among the requirement information, the number of requirement information of information (which may be identification information of the transaction processing device) indicating that the transaction processing device is to be processed is extracted. Count. First, the requirement information of the information indicating that the transaction processing device should be processed (which may be the identification information of the transaction processing device) is extracted, and the processed flag is detected from among them. Also good.
次にステップ1032において、ステップ1031で未処理の案件があるか否かを判断する。この結果、ない場合にはそのままステップ115に進み、本ステップ103を終了する。ある場合には、ステップ1033に進む。
Next, in
ステップ1033において、自身に送信するすなわち再送のMQを編集(生成)する。上述したように、MQはトリガーとなればよいので、自身(取引処理装置)であること識別する情報が含まれればよい。但し、より好適には、MQには当該取引処理装置が属するグループ(もしくは取引処理装置自身)を識別するグループコードもしくは対応する要件情報の登録などの処理時間等のキー情報を含めてもよい。また、ここでは、ステップ1031で計数された未処理の件数以下の数のMQを生成する。より好適には、未処理の件数未満とするとよい。これは、この再送MQによりトランザクションの増加やキュー溢れを防止するためのもので、その数はこれらを考慮して適当に定めてもよい。 In step 1033, the MQ to be transmitted to itself, that is, the retransmission MQ is edited (generated). As described above, since MQ may be a trigger, information identifying itself (transaction processing apparatus) may be included. However, more preferably, MQ may include key information such as a group code for identifying a group to which the transaction processing apparatus belongs (or the transaction processing apparatus itself) or processing time such as registration of corresponding requirement information. Here, the number of MQs equal to or less than the number of unprocessed cases counted in step 1031 is generated. More preferably, it may be less than the number of unprocessed cases. This is to prevent an increase in transactions and overflow of the queue by this retransmission MQ, and the number thereof may be appropriately determined in consideration of these.
そして、ステップ1034に進み、再送MQを自プロセス(取引処理装置)に向けて送信する。そして、本処理を終了し(ステップ1035)、ステップ115に進む。 Then, the process proceeds to step 1034, and the retransmission MQ is transmitted to the own process (transaction processing apparatus). Then, this process is terminated (step 1035), and the process proceeds to step 115.
次に、ステップ115に進み、本トランザクションに決着がつけられたことになり、ステップ104に進む。ステップ104において、ステップ101と同様に、処理依頼を取得する。そして、ステップ105では、ステップ102と同様にタイムアウトしたか否かを検知する。ここでのタイムアウト値は、ステップ102でのそれと比べて長くしてもよい。この結果、タイムアウトとなった場合には、ステップ106に進みステップ103と同様の処理を実行する。
Next, the process proceeds to step 115, where the transaction is settled, and the process proceeds to step 104. In step 104, as in
次に、ステップ102やステップ105で、タイムアウトがないと判断された場合について、説明する。このように判断された場合、ステップ107に進む。ステップ107では、ステップ103や106で再送されたMQを含み自身に送信されたMQを記憶装置から取得する。ここで、取得されたMQを格納していた記憶装置から削除する。
Next, a case where it is determined in
次に、ステップ108において、MQの取得に対応して、要件データベース(要件DB)から1件の要件情報を取得する。ここで、1件の要件情報の取得の方法は、MQに含まれるキー情報と、図5に示す要件データベースの内容(キー情報、時間情報(図示せず))を用いて行う。すなわち、要件情報に含まれる要件情報のうち、処理済フラグが未処理であり、当該取引処理装置で登録が最も古い要件情報を選択する(キー情報やUAP情報にこれらの情報を含ませて構成することが可能である)。このようにして、要件情報が選択できない場合はステップ115に進み、選択した場合はステップ110に進む。 Next, in step 108, corresponding to the acquisition of MQ, one piece of requirement information is acquired from the requirement database (requirement DB). Here, the acquisition method of one requirement information is performed using the key information included in the MQ and the contents (key information, time information (not shown)) of the requirement database shown in FIG. That is, among the requirement information included in the requirement information, the requirement information whose processed flag is unprocessed and whose registration is the oldest in the transaction processing device is selected (this information is included in key information and UAP information. Is possible). In this way, if the requirement information cannot be selected, the process proceeds to step 115, and if selected, the process proceeds to step 110.
次に、ステップ110において、選択された要件情報に対応する取引処理を、当該要件情報を用いてアプリケーションプログラムに従って実行する。 Next, in step 110, transaction processing corresponding to the selected requirement information is executed according to the application program using the requirement information.
このステップ110の終了後もしくはステップ110と並行して、ステップ111〜114の処理を実行する。ステップ111において、ステップ100以降の再送MQの数を計数する。これは、MQ内に件数を含ませ、それをカウントすることで実現する。なお、発行の度にカウントし、記録することで行ってもよい。実現可能である。この結果、再送MQが0件の場合、ステップ115に進む。0件でない場合には、ステップ112に進む。 After the completion of step 110 or in parallel with step 110, the processes of steps 111 to 114 are executed. In step 111, the number of retransmission MQs after step 100 is counted. This is realized by including the number of cases in the MQ and counting it. In addition, it may be performed by counting and recording each time it is issued. It is feasible. As a result, when the number of retransmission MQ is 0, the process proceeds to step 115. If it is not 0, the process proceeds to step 112.
ステップ112では、再送MQの件数が格納された記憶装置から再送件数を1減算するよう演算する。そして、一定時間を経過したかを検知して(ステップ113)、その結果した場合にはステップ114に進み、ステップ103などと同様に再送処理を実行する。なお、ステップ113で一定時間を経過したと検知しなかった場合には、ステップ115に進む。ここで、一定時間が経過したか否かの確認は、一部の装置の障害やキュー溢れに対応するために監視を行うために実行する。ここでは、再送件数を記憶装置に格納するようにしたが、以下のように構成してもよい。メモリ等への一時的な格納はするが、再送するMQに再送件数を含ませる。つまり、ステップ112では、ステップ111で計数した再送件数から1減算した再送件数を含むMQを再送する。
In step 112, calculation is performed so as to subtract 1 from the number of retransmissions from the storage device in which the number of retransmissions MQ is stored. Then, it is detected whether a predetermined time has passed (step 113). If the result is affirmative, the process proceeds to step 114, and retransmission processing is executed in the same manner as in
以上の実施の形態の処理によれば、図6および以下に示される効果を達成することが可能になる。要件DBが登録できてさえいれば,要件登録順での業務処理続行可能である。また,MQ再送処理により大幅な遅延なく処理可能になる。特に、以下のような場合に対応が可能になる。(1)一部の参加者(証券会社等)からの多量注文入力などによって,処理依頼元サーバのMQのキューあふれが発生したケース、(2)特定の銘柄に注文が集中するなどによって,処理依頼先のMQのキューあふれが発生したケース、(3)処理依頼先サーバのダウンなどによって,MQが消失したケース、(4)処理依頼先プロセスのダウンなどによってMQが削除されず,結果としてMQのキューあふれが発生したケース。 According to the processing of the above embodiment, the effects shown in FIG. 6 and the following can be achieved. As long as the requirement DB can be registered, business processing can be continued in the order of requirement registration. In addition, processing can be performed without significant delay by MQ retransmission processing. In particular, it is possible to cope with the following cases. (1) A case in which the MQ queue overflow of the processing request source server occurs due to large-scale order input from some participants (such as securities companies), (2) Processing due to orders concentrated on a specific issue, etc. Requested MQ queue overflow, (3) MQ lost due to processing request destination server down, etc. (4) MQ not deleted due to processing request destination process down, resulting in MQ When the queue overflow occurred.
本実施の形態のように、MQをトリガーとして取り扱うことで、
・データベースに蓄積された注文を時間優先順の原則に従って処理する
・レスポンスの高速化と単位時間処理件数の向上
することが可能になる。
By handling MQ as a trigger as in this embodiment,
・ Process the orders stored in the database according to the principle of time priority. ・ It is possible to increase the response speed and the number of unit time processing.
そして、本実施の形態による回復処理では,
・特定銘柄への注文集中などによって,MQが部分的に消失してしまった場合でも,極力遅滞なく注文の処理を行うことが可能になる。なお、本実施の形態では、MQ(障害時に回復対象にならない)を含む(永続MQが混在しても構わない)場合に有効である。例えば注文受付プロセスは複数の通信サーバに配置される。この場合、あるサーバでMQの転送遅延や,転送途中での障害が発生した際,該当する注文の発注元取引参加者は,他の取引参加者に遅れを取る形になったり,銘柄の取引状態が変化することで不利をこうむったりする恐れがあることを解消できる。
In the recovery process according to this embodiment,
・ Even if MQ is partially lost due to concentration of orders on specific issues, it is possible to process orders without delay as much as possible. Note that this embodiment is effective in the case of including MQ (not subject to recovery in the event of a failure) (permanent MQ may be mixed). For example, the order reception process is arranged in a plurality of communication servers. In this case, when an MQ transfer delay or failure occurs in the middle of a server, the ordering transaction participant of the corresponding order may be behind the other transaction participants, It is possible to eliminate the risk of suffering disadvantages due to changes in the state.
1…取引端末、2…受付装置、3…取引処理装置、4…約定処理装置
DESCRIPTION OF
Claims (6)
前記複数の処理装置は、少なくとも前記証券取引処理の一部を実行するための処理依頼であって発行後効力が消滅することがある処理依頼を発行する第1の処理装置および前記処理依頼(項番8)に応じた処理を実行する第2の処理装置を含み、
前記第1の処理装置が、
前記処理依頼を発行し、
前記処理依頼に対応する前記処理依頼で実行すべき処理を実行するための要件情報を要件データベースに格納し、
前記第2の処理装置が、
発行された処理依頼の有無を確認し、
(1)前記処理依頼がある場合には、対応する要件情報を前記要件データベースから検索して、対応する処理を実行し、
(2)前記処理依頼がない場合には、前記要件データベースを検索して、自身で実行すべき処理のうち、未処理の要件情報を検索し、
未処理の要件情報がある場合には、自身に対して未処理の要件情報があることに対応する依頼情報を発行し、
前記依頼情報を受けて前記要件データベースから、対応する要件情報を取得して、該当する処理を実行することを特徴とする取引システム。 In a transaction system, each of which is a plurality of transaction terminals belonging to any of a plurality of groups, connected to a transaction terminal that transmits a transaction request, and configured from a plurality of processing devices to perform a securities transaction process corresponding to the transaction request ,
The plurality of processing devices are a processing request for executing at least a part of the securities transaction processing, and issues a processing request that may become invalid after issuing the processing request and the processing request (section) Including a second processing device that executes processing according to No. 8),
The first processing apparatus is
Issue the processing request,
Storing requirement information for executing processing to be executed in the processing request corresponding to the processing request in a requirements database;
The second processing device comprises:
Check for issued processing requests,
(1) When there is the processing request, the corresponding requirement information is searched from the requirement database, the corresponding processing is executed,
(2) If there is no processing request, the requirement database is searched for unprocessed requirement information among the processing to be executed by itself.
If there is unprocessed requirement information, issue request information corresponding to the existence of unprocessed requirement information to itself,
A transaction system that receives the request information, acquires corresponding requirement information from the requirement database, and executes a corresponding process.
前記第2の処理装置は、前記未処理の処理依頼がある場合、当該未処理の要件情報の件数を計数し、
前記該当する処理を実行した場合もしくは前記対応する要件情報を取得した場合、計数された前記件数を1減算し、
減算された前記件数が0を示すまで自身への依頼情報の発行を繰り返すことを可能とすることを特徴とする取引システム。 The transaction system according to claim 1,
When there is an unprocessed processing request, the second processing device counts the number of the unprocessed requirement information,
When the corresponding process is executed or when the corresponding requirement information is acquired, the counted number is subtracted by 1,
It is possible to repeat the issue of request information to itself until the subtracted number of cases indicates 0.
前記処理依頼および前記依頼情報の少なくとも一方は、一定時間後に自身の効力が消滅する情報であることを特徴とする取引システム。 In the transaction system according to claim 1 or 2,
At least one of the processing request and the request information is information whose own effect disappears after a predetermined time.
前記第2の処理装置は、前記処理依頼および前記依頼情報を記憶装置に格納し、
前記処理依頼および前記依頼情報のうち少なくとも一方の効力が消滅したことを検知し、当該検知した場合に、前記処理依頼がないと判定することを特徴とする取引システム。 In the transaction system according to claim 3,
The second processing device stores the processing request and the request information in a storage device,
A transaction system that detects that at least one of the processing request and the request information has expired, and determines that there is no processing request when the detection is detected.
前記処理依頼および前記依頼情報は、転送キューであることを特徴とする取引システム。 In the transaction system according to claim 3 or 4,
The transaction system, wherein the processing request and the request information are a transfer queue.
前記第2の処理装置は、自身に対する依頼情報を、計数された前記未処理の要件情報の件数以下であることを特徴とする取引システム。
The transaction system according to any one of claims 2 to 5,
The transaction system, wherein the second processing device has the request information for itself equal to or less than the number of unprocessed requirement information counted.
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006047667A JP4797689B2 (en) | 2006-02-24 | 2006-02-24 | Trading system |
US11/656,993 US8768817B2 (en) | 2006-01-26 | 2007-01-24 | Transaction system |
KR20070008616A KR100905353B1 (en) | 2006-01-26 | 2007-01-26 | Trading system |
KR1020080062023A KR100943110B1 (en) | 2006-01-26 | 2008-06-27 | Trading system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006047667A JP4797689B2 (en) | 2006-02-24 | 2006-02-24 | Trading system |
Publications (3)
Publication Number | Publication Date |
---|---|
JP2007226584A true JP2007226584A (en) | 2007-09-06 |
JP2007226584A5 JP2007226584A5 (en) | 2008-12-18 |
JP4797689B2 JP4797689B2 (en) | 2011-10-19 |
Family
ID=38548342
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006047667A Expired - Fee Related JP4797689B2 (en) | 2006-01-26 | 2006-02-24 | Trading system |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4797689B2 (en) |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH11238046A (en) * | 1997-11-21 | 1999-08-31 | Fuji Xerox Co Ltd | Computer system |
JP2004157776A (en) * | 2002-11-06 | 2004-06-03 | Nec Corp | Processing method for application and system |
-
2006
- 2006-02-24 JP JP2006047667A patent/JP4797689B2/en not_active Expired - Fee Related
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH11238046A (en) * | 1997-11-21 | 1999-08-31 | Fuji Xerox Co Ltd | Computer system |
JP2004157776A (en) * | 2002-11-06 | 2004-06-03 | Nec Corp | Processing method for application and system |
Also Published As
Publication number | Publication date |
---|---|
JP4797689B2 (en) | 2011-10-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8768817B2 (en) | Transaction system | |
CN107992398B (en) | Monitoring method and monitoring system of service system | |
US7480918B2 (en) | Duplicate message elimination during recovery when multiple threads are delivering messages from a message store to a destination queue | |
US9158649B2 (en) | Methods and computer program products for generating a model of network application health | |
US20200133750A1 (en) | Methods, apparatus and computer programs for managing persistence | |
US8516509B2 (en) | Methods and computer program products for monitoring system calls using safely removable system function table chaining | |
US7698251B2 (en) | Fault tolerant facility for the aggregation of data from multiple processing units | |
US8909761B2 (en) | Methods and computer program products for monitoring and reporting performance of network applications executing in operating-system-level virtualization containers | |
US8645532B2 (en) | Methods and computer program products for monitoring the contents of network traffic in a network device | |
JP2009531750A (en) | Method and system for risk monitoring in online business | |
CN107517110A (en) | Veneer configuration self-recovery method and device in a kind of distributed system | |
US7954112B2 (en) | Automatic recovery from failures of messages within a data interchange | |
CN101438275A (en) | Work item event procession | |
CN101009017A (en) | Trading system | |
JP2004046338A (en) | Computer system | |
KR101499890B1 (en) | Low Latency Framework System | |
US20100058158A1 (en) | Method and system for detecting gaps in a data stream | |
JP4797689B2 (en) | Trading system | |
CN111652681A (en) | Receipt processing method, server and computer readable storage medium | |
JP5136200B2 (en) | Logging system | |
CN106789272A (en) | A kind of server set group managing means and system | |
JP2005284357A (en) | Log analyzing program and log analyzing device | |
US20120296951A1 (en) | System and method to execute steps of an application function asynchronously | |
CN114363416B (en) | Cross-chain processing method and device based on block chain, storage medium and server | |
JP4271612B2 (en) | Fault detection system and method |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081029 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20081029 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20110328 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110419 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110609 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20110705 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20110718 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140812 Year of fee payment: 3 |
|
R151 | Written notification of patent or utility model registration |
Ref document number: 4797689 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140812 Year of fee payment: 3 |
|
LAPS | Cancellation because of no payment of annual fees |