JP4786218B2 - Information processing apparatus, information processing apparatus control method, and program - Google Patents

Description

  The present invention relates to an information processing apparatus, a control method for the information processing apparatus, and a program.

Today, in stock exchanges and commodity exchanges, trading targets such as stocks and various products are actively traded every day. With the advancement of information technology, these transactions have been carried out using computer systems.
The exchange receives orders for various stocks from many customers every day, but these orders must be processed quickly and fairly.
For this reason, various technologies are employed in computer systems used for transactions at exchanges (see, for example, Patent Document 1).
Japanese Patent Laid-Open No. 2002-324022

  By the way, in order to realize a quick process by processing in parallel these orders sent in large quantities to an exchange, consideration for the order of transactions is required in order to make the transactions fair. That is, it is necessary to prevent an order placed later for a brand from being processed before an order placed earlier for the brand.

  For this reason, when dealings are processed in parallel, it is necessary to place orders for different brands. In this case, from the viewpoint of processing efficiency and the like, each brand listed on the exchange is classified into a plurality of brand groups and processed in parallel between the brand groups.

  In this case, consideration must be given to the load balance between each brand group. For example, in the case of stock trading, there is a case where orders for a specific brand are flooded due to sudden news or the like. In this case, the processing load for a certain brand group increases. For this reason, there is a demand for a technique that can quickly move the brand to another brand group without stopping the trade and keep the order of the trade, thereby achieving load distribution among the brand groups.

  Further, when a failure occurs in the computer system during the transaction, it is required not to affect the transaction. For this reason, it is possible to quickly move each stock classified into the stock group affected by the failure to the stock group not affected by the failure without stopping the trading and keeping the order of the trading. This technology is desired.

  The present invention has been made in view of the above problems, and an information processing apparatus capable of quickly changing the distribution of processing while maintaining the order of transactions while maintaining the transaction, a control method for the information processing apparatus, and a program The main purpose is to provide

  In order to solve the above problems, the present invention shows each identifier of a plurality of stock groups obtained by classifying each stock subject to be traded in the market, and each stock subject to be traded classified into each stock group. A stock group management table that correlates information with each other, a trade request receiving unit that receives a plurality of trade requests in which information indicating the stocks to be traded is written, and a transaction that is described in each trade request. A transaction request storage unit that stores information associated with each of the target brands in association with an identifier of each brand group that is associated with each other, and each transaction request that is stored in the transaction request storage unit in the order in which they are stored. A plurality of transaction processing units that read out each time for transaction processing, and a brand group that identifies a transaction request that each transaction processing unit reads from the transaction request storage unit. A read management table that stores an identifier in association with an identifier of each transaction processing unit, and a brand group in which a brand to be traded is classified is changed from the first brand group to the second brand group. Changing the identifier of the brand group associated with the information indicating the brand to be traded in the brand group management table from the identifier of the first brand group to the identifier of the second brand group, The identifier of each brand group associated with each trade request in which information indicating the brand to be traded is described in the trade request storage unit is also determined from the identifier of the first brand group to the second brand group. And a brand group update processing unit that changes the identifier to an information processing apparatus.

  In addition, the problems disclosed by the present application and the solutions thereof will be clarified by the column of the best mode for carrying out the invention and the drawings.

  It is possible to provide an information processing apparatus, a control method for the information processing apparatus, and a program that can quickly change the distribution of processes while continuing the transaction and keeping the order of the transaction.

=== First Embodiment ===
=== Example of Overall Configuration ===
FIG. 1 shows the overall configuration of the exchange system according to the first embodiment. The exchange system according to the present embodiment is a computer system that performs stock trading on a stock exchange. Of course, trading is not limited to stocks, but securities, gold, soybeans, raw silk, corn, shrimp, coffee beans, aluminum, rubber, etc. may be traded on stock exchanges and commodity exchanges. it can.

  The exchange system is configured such that an order reception server 300 and a transaction execution server (corresponding to an information processing device described in claims) 200 are communicably connected via a network 400.

  The exchange system is communicably connected to the order input terminal 100 via the network 400. The order input terminal 100 is a computer possessed by a securities company or the like that accepts stock trading orders from investors. Although one order input terminal 100 is shown in FIG. 1, a plurality of order input terminals 100 may be provided. The order input terminal 100 transmits an order message (corresponding to a transaction request described in claims) 600 to the order reception server 300 as shown in FIG.

  As shown in FIG. 10, the order message 600 includes columns of “market code”, “product code”, “brand code”, “member code”, “trade”, “price”, and “quantity”. In the “market code” column, information indicating the stock market is described. The stock market may be, for example, the first and second markets on the Osaka Stock Exchange, the Hercules market, the first market on the Tokyo Stock Exchange, and the like. In the “product code” column, information indicating the type of transaction such as “future transaction” or “option transaction” is described. In the “stock code” column, information indicating the stock brand is described. In the “member code” column, identification information of the securities company is described. In the “Buy / Buy” column, information indicating whether to buy or sell stock is written. In the “price” column, information indicating the desired buying / selling price of the stock is described. In the “quantity” column, information indicating the quantity of shares desired to be traded is written.

  When the order message 600 is transmitted to the order receiving server 300, the order receiving server 300 and the transaction execution server 200 process stock transactions.

  When receiving the order message 600 from the order input terminal 100, the order reception server 300 stores the contents of the order message 600 in the order reception database 700 in association with the order number. The order reception database 700 is shown in FIG. The order number is a number uniquely given to each order by the order receiving server 300. Then, the order reception server 300 refers to the brand group definition database (corresponding to the brand group management table described in the claims) 710 shown in FIG. 7 and the brand indicated by the brand code described in the order message 600 is Acquires the identifier (brand group number) of the brand group to be classified. The stock group definition database 710 associates each identifier of a plurality of stock groups obtained by classifying stock stocks in the stock market with information indicating each stock stock classified in each stock group. is there. As shown in FIG. 7, the brand group can be classified not only by brand code but also by product code or market code. By doing in this way, it is possible to classify stock stocks that are more detailed according to the form of trading.

  Subsequently, the order reception server 300 uses the requirement database (corresponding to the transaction request storage unit described in claims) 720 to store the order data obtained by associating the acquired brand group number, the order number, and the brand key. To remember. The storage in the requirement database 720 is performed by transmitting the order data to the transaction execution server 200, and the transaction execution server 200 writes the received order data into the requirement database 720. The order data is associated with the order message (transaction request) 600 stored in the order reception database 700 by the order number. Therefore, of course, the order message 600 may be directly stored in the requirement database 720 in association with the brand group number. The requirement database 720 is shown in FIG. The brand key is a combination of a market code, a product code, and a brand code as one code. In the “requirement creation time” column of the requirement database 720, information indicating the time when the order data is written in the requirement database 720 is stored. In the “processing flag” column, information indicating whether or not transaction processing is performed for each order data is described. The transaction execution server 200 sets the “processing flag” field to “unprocessed” and writes the order data in the requirement database 720.

  Then, the transaction execution server 200 performs transaction processing for each order data written in the requirement database 720. The transaction execution server 200 executes a plurality of transaction processing processes (corresponding to transaction processing units described in claims) 811 for performing processing on each order data. Each transaction processing process 811 is assigned a brand group number, and performs processing for the order data of the assigned brand group number. The brand group number allocated to each transaction processing process 811 is described in a transaction processing allocation database (corresponding to the read management table described in the claims) 750 shown in FIG. Each transaction processing process 811 stores each order data stored in the request database 720 based on the time information described in the “requirement creation time” column and the brand group number described in the “brand group number” column. The transaction processing is performed by reading out each stock group in the order in which they are performed (in the oldest order). In this way, each order data can be processed in parallel on a brand group basis while maintaining the order. The result of the transaction for each order data is stored in the brand database 730 and the walk database 740. Order data for each brand is stored in the brand database 730, and the transaction processing process 811 establishes a sale between a sell order and a buy order that meet the conditions. The history database 740 stores history information of all transactions from the past to the present. When the transaction processing is performed on the order data stored in the request database 720, the “processing flag” column of the order data is updated to “processed” by the transaction processing process 811.

  Further, the transaction execution server 200 executes a monitoring process (corresponding to a reception number comparison unit described in claims) 813. The monitoring process 813 compares the number of stock transaction requests received per unit time, for example, the number of order data written in the requirement database 720 per unit time, with the judgment value for each brand group. This makes it possible to detect that the number of transactions for a certain brand group has increased rapidly. For example, if the number of transactions for a certain brand classified into a certain brand group increases due to news of a new product announcement, for example, the processing is delayed for other brands classified into that brand group. In this case, therefore, the brands are exchanged or moved between the brand groups in order to distribute the processing load among the brand groups.

  Here, the exchange and movement of the brands between the brand groups can be performed by updating the brand group definition database 710. However, simply updating the brand group definition database 710 causes the new order message 600 to be updated. The stock group will be determined according to the new classification, but each order data stored in the requirement database 720 will be processed as the stock group according to the old classification. become. Therefore, in this case, even if the classification of the brand group is changed immediately, the processing with the classification that is still for a considerable period is performed. Therefore, in the present embodiment, the brand group definition database 710 is updated, and the brand group number of each order data stored in the requirement database 720 is also updated. Thereby, it is possible to immediately start processing in a new classification together with the change of the classification of the brand group. This is extremely important in transactions such as stocks that require rapid processing. The update of the brand group definition database 710 and the update of the requirement database 720 are performed by an operation management process (corresponding to the brand group update processing unit described in claims) 812.

  Further, the transaction execution server 200 according to the present embodiment executes a failure detection process (corresponding to an abnormality detection unit described in claims) 814. The failure detection process 814 detects an abnormality of each transaction processing process 811. When an abnormality occurs in a certain transaction processing process 811, the processing of the stock group to be processed by the transaction processing process 811 is affected. Therefore, in such a case, the processing must be immediately taken over by a normal transaction processing process 811. Therefore, the operation management process 812 according to the present embodiment, when an abnormality is detected in a certain transaction processing process 811, each issue classified into the issue group processed by the transaction processing process 811 is changed to another issue. In order to move to the group, the brand group definition database 710 is updated, and the brand group number of each order data stored in the requirement database 720 is also updated. As a result, it is possible to immediately take over the processing to the normal transaction processing process 811 in accordance with the change of the classification of the brand group when the failure of the transaction processing process 811 occurs. Note that the transaction processing process can be taken over by updating the transaction processing allocation database 750.

  In FIG. 1, one order receiving server 300 and one transaction execution server 200 are shown, but a plurality of order receiving servers 300 and a plurality of transaction executing servers 200 may be used. Further, the function realized by the order receiving server 300 may be realized by the transaction execution server 200, and the order receiving server 300 may not be provided.

=== Device configuration ===
Next, hardware configurations of the order input terminal 100, the order reception server 300, and the transaction execution server 200 will be described.
The order input terminal 100, the order reception server 300, and the transaction execution server 200 are all computers, and the hardware configuration is basically the same. Therefore, these hardware configurations are summarized in one block diagram and shown in FIG. Further, control programs and tables for realizing these functions are shown in FIGS.

<Configuration of transaction execution server>
First, the configuration of the transaction execution server 200 will be described.

  The transaction execution server 200 includes a CPU (Central Processing Unit) 210, a memory 220, a port 230, a recording medium reading device 240, an input device 250, an output device 260, and a storage device 280.

  The CPU 210 is responsible for overall control of the transaction execution server 200, and is a transaction execution server control program comprising codes for performing various operations according to the present embodiment stored in the storage device 280. 810) (corresponding to the program described in the above) is read into the memory 220 and executed, thereby realizing various functions as the transaction execution server 200. For example, the transaction execution server control program 810 is executed by the CPU 210 and cooperates with hardware devices such as the memory 220, the port 230, the input device 250, the output device 260, the storage device 280, etc. A group management table, a transaction request reception unit, a transaction request storage unit, a transaction processing unit, a read management table, a brand group update processing unit, a reception number comparison unit, and an abnormality detection unit are realized. The memory 220 can be constituted by a semiconductor memory device, for example.

The recording medium reading device 240 is a device for reading a program and data recorded on the recording medium 500. The read program and data are stored in the memory 220 and the storage device 280. Therefore, for example, the transaction execution server control program 810 recorded in the recording medium 500 can be read from the recording medium 500 using the recording medium reading device 240 and stored in the memory 220 or the storage device 280.
As the recording medium 500, a flexible disk, a magnetic tape, a compact disk, or the like can be used. The recording medium reading device 240 can be built in the transaction execution server 200 or can be externally attached.

  The storage device 280 can be, for example, a hard disk device or a semiconductor storage device. The storage device 280 stores a transaction execution server control program 810, a brand group definition database 710, a requirement database 720, a brand database 730, a step database 740, and a transaction processing allocation database 750. Hereinafter, “database” may be referred to as “DB”.

  The trade execution server control program 810 is a program for processing stock transactions in accordance with stock trading orders from customers. By executing the transaction execution server control program 810 by the CPU 210, a transaction processing process 811, an operation management process 812, a monitoring process 813, and a failure detection process 814 are realized.

The input device 250 is a device used for data input to the transaction execution server 200 and functions as a user interface. For example, a keyboard or a mouse can be used as the input device 250.
The output device 260 is a device for outputting information to the outside and functions as a user interface. For example, a display or a printer can be used as the output device 260.

  The port 230 is a device for performing communication. For example, communication with other computers such as the order receiving server 300 and the order input terminal 100 performed via the network 400 can be performed via the port 230. Further, for example, the transaction execution server control program 810 can be received from another computer via the port 230 via the network 400 and stored in the memory 220 or the storage device 280.

<Configuration of order reception server>
Next, the configuration of the order reception server 300 will be described. The order receiving server 300 includes a CPU 310, a memory 320, a port 330, a recording medium reading device 340, an input device 350, an output device 360, and a storage device 380. The functions of these devices are the same as those of the devices included in the transaction execution server 200 described above.

As shown in FIG. 5, in the storage device 380 provided in the order receiving server 300, an order receiving server control program 820 including codes for performing various operations according to the present embodiment and an order receiving database 700 are stored. Is done.
Various functions as the order receiving server 300 are realized by the CPU 310 reading the order receiving server control program 820 into the memory 320 and executing it. Various functions as the order reception server 300 are realized by an order reception processing process 821.

<Configuration of order entry terminal>
Next, the configuration of the order input terminal 100 will be described. The order input terminal 100 includes a CPU 110, a memory 120, a port 130, a recording medium reading device 140, an input device 150, an output device 160, and a storage device 180. The functions of these devices are the same as those of the devices included in the transaction execution server 200 described above.

As shown in FIG. 3, the order input terminal control program 800 including codes for performing various operations according to the present embodiment is stored in the storage device 180 included in the order input terminal 100.
Various functions as the order input terminal 100 are realized by the CPU 110 reading the order input terminal control program 800 into the memory 120 and executing it.

=== Flow of processing ===
Next, the flow of processing in the exchange system according to the present embodiment will be described with reference to FIGS.

<Order acceptance processing>
First, stock order reception processing performed in the order reception server 300 will be described with reference to FIG.

  Upon receiving the order message 600 from the order input terminal 100 (S1000), the order reception server 300 stores the order message with the order reception number in the order reception database 700 (S1010). The order reception number is the order number described above.

  Next, the order reception server 300 confirms whether or not the lock is released (S1020). Although details will be described later, the transaction execution server 200 is locked when the transaction execution server 200 is updating the requirement database 720 and the stock group definition database 710. Whether or not the lock is released is stored in the storage device 280 provided in the transaction execution server 200. If the lock is not released, the order reception server 300 waits until the lock is released.

  If the lock is released, the order reception server 300 searches the brand group definition database 710 using the brand key included in the order message 600, and determines the brand group in charge (S1030). The brand key is a collection of the market code, the product code, and the brand code as one code as described above. Then, the order reception server 300 transmits the order data to the transaction execution server 200. Then, the order data, the requirement creation time, and the processing flag are written in the requirement database 720 (S1040).

  The order reception server 300 then communicates a processing request (issues an event) to the transaction processing process 811 executed in the transaction execution server 200 (S1050).

<Transaction processing>
Next, stock transaction processing performed by each transaction processing process 811 executed in the transaction execution server 200 will be described with reference to FIG.

  First, the transaction process 811 receives a transaction event from the order reception server 300 (S2000). Then, the transaction processing process 811 confirms whether or not the lock is released (S2010). When the lock is released, the transaction processing process 811 refers to the transaction processing allocation database 750 to identify the brand group number to be processed (S2020). Then, the transaction processing process 811 extracts unprocessed records (order data) from the requirement database 720 in ascending order of creation time (from the oldest) using the brand group number to be processed as a key (S2030).

  Subsequently, the transaction processing process 811 refers to the order reception database 700 provided in the order reception server 300, extracts an order using the order number in the requirement database 720 as a key, and performs a sales transaction process (S2040). Then, the result of the transaction is stored in the brand database 730 and the walk database 740 (S2050). Then, the record in the requirement database 720 is updated to “processed” (S2060).

<Stock Group Update Processing>
Next, the brand group update process performed by the operation management process 812 executed in the transaction execution server 200 will be described with reference to FIG.

  First, the operation management process 812 receives a brand group change notification event from the monitoring process 813 or the failure detection process 814 (S3000). Here, as an example, it is assumed that the brand A classified into the brand group 1 is changed to the brand group 2. Then, the operation management process 812 first locks (S3010). For example, the lock can be applied by rewriting a flag stored in the storage device 280 indicating whether or not the lock is applied to a value indicating that the lock is applied.

  Subsequently, the operation management process 812 changes the stock group number from the stock group 1 to the stock group 2 for the stock order data related to the stock A stored in the requirement database 720 (S3020). Furthermore, the operation management process 812 changes the brand group number associated with the brand A stored in the brand group definition database 710 from the brand group number 1 to the brand group number 2 (S3030).

  Then, the operation management process 812 releases the lock (S3040). The lock can be released by rewriting the above-described flag indicating whether or not the lock is applied to a value indicating that the lock is not applied.

  Then, the operation management process 812 issues an event to the transaction processing process 811 that performs the stock transaction processing for the brand group 2 (S3050).

=== Second Embodiment ===
The first embodiment may be a second embodiment as described below.
FIG. 14 shows the overall configuration of the exchange system according to the second embodiment. The exchange system according to the present embodiment includes an order reception server 300, a transaction execution server 200, an order reception database 700, a brand group definition database 710, a requirement database 720, a brand group instruction state database 760, and a stay. A brand temporary allocation determination database 770 is connected to be communicable via the network 400. The exchange system is communicably connected to the order input terminal 100 via the network 400. Also in the present embodiment, the order receiving server 300 and the transaction execution server 200 may be plural. Further, the function realized by the order receiving server 300 may be realized by the transaction execution server 200, and the order receiving server 300 may not be provided.

  The order input terminal 100 is a terminal that can be connected via the network 400 connected to the exchange system and can transmit the order message 600 to the exchange system. An example interface of the order message 600 is shown in FIG.

  The order reception server 300 is a server that receives the order message 600 transmitted from the order input terminal 100 and relays it to the transaction execution server 200 of the exchange system. Usually, a plurality of order reception processing processes 821 are executed in each order reception server 300.

  The order reception processing process 821 stores the order message 600 received from the order input terminal 100 in the order reception DB 700, generates a brand key from the contents of the order message 600 (brand code and information associated therewith), and uses the brand key as a brand. This is a process of determining a brand group number according to the group definition DB 710 and requesting an order registration processing process 817 for the brand group number for a trading transaction process. This is shown in FIG. Further, the request for the sales transaction processing is performed by transmitting the requirement processing request event shown in FIG. 23 to the order registration processing process 817. The order registration process 817 is a process executed by the transaction execution server 200. Normally, one order reception processing process 821 is connected in charge of a plurality of order input terminals 100.

  On the other hand, in the transaction execution server 200, a brand group processing process 815, a brand group change processing process 812, an active brand temporary allocation process 813, and a brand group failure temporary allocation process 814 are executed. The transaction processing process 811 described in the first embodiment is one of the processes included in the stock group processing process 815. That is, as shown in FIG. 15, the brand group processing process 815 according to the present embodiment includes an order registration processing process 817, a transaction processing process 811, and an acceptance notification creation processing process 816. The stock group change processing process 812, the active stock temporary allocation processing process 813, and the stock group fault temporary allocation processing process 814 are the operation management process 812, monitoring process 813, and fault detection process described in the first embodiment, respectively. This corresponds to 814.

  The brand group processing process 815 is executed for each brand group obtained by grouping a plurality of brands for the purpose of processing load distribution. Each brand group unit is given a series of brand group numbers. Each stock has a unique stock group number. The brand group processing process 815 performs a series of processes related to sales transactions in units corresponding to these brand groups in order to guarantee the principle of time priority for each brand. A series of processes refers to each process performed sequentially, as shown in FIG. 15, for example, that a transaction process is performed after the order registration process.

  The brand group processing process 815 is also provided with a spare brand group processing process 815 in which the assigned number of brands in charge is defined as zero in advance. This is because if the active stock is moved to the assigned stock group, the processing of other stocks in the destination stock group will get caught up and stay in the live stock, so one or more spare stock groups will be created in advance. Prepared, if it is necessary to move the active issue, move to the reserve issue group, so that the active issue will have the maximum processing speed allowed by the issue group processing process 815 and other issues. This is because it is possible to make transactions possible without adversely affecting the business. In particular, in order to be able to automatically select a spare stock group as a stock group to be changed in the active stock temporary allocation process 813 and the stock group failure temporary allocation processing process 814 that are automatically operated, the stock group indication state DB 760 is used. It is assumed that a flag is assigned in advance to the spare issue group number.

  The brand group change process 812 is divided into a brand group change (brand key designation) process 812 and a brand group change (brand group designation) process 812.

  The brand group change (brand key designation) processing process 812 operates in response to an instruction from the operator or an instruction input from the active brand temporary allocation processing process 813. The instruction is input by receiving a brand group change (brand designation) processing request event shown in FIG. A brand group change (brand key designation) process 812 performs a process for changing the assignment of the designated brand key from the designated source brand group to the designated destination brand group.

  The brand group change (brand group designation) processing process 812 operates in response to an instruction from the operator or an instruction input from the brand group failure temporary allocation processing process 814. The instruction is input by receiving a brand group change (brand group designation) processing request event shown in FIG. A brand group change (brand group designation) process 812 performs a process for changing the assignment of the brand keys of all brands belonging to the designated source brand group number to the designated brand group to be changed.

  Such a change of the brand group is performed, for example, when a trading transaction of a specific brand becomes active. This is shown in FIGS.

  In general, buying and selling transactions of a particular brand are booming due to news reports, occurrence of contingencies, business announcements, political comments, and the like. Sales transactions are suddenly booming and difficult to predict in advance. Further, in this case, a large number of trading orders that are not normally assumed for one brand are concentrated in a short time. As a result, the transaction processing of the brand is extremely slow as compared with normal times, and the transaction processing response of other brands belonging to the same brand group is also deteriorated.

  Normally, it is very difficult to allocate system resources for all stocks in order to cope with sudden situations. Then, the action of “Prohibition of order under specific conditions” or “Limitation of trading matching time” is taken. For example, “Prohibit placing orders for market orders (ordering conditions for establishing trading at any price without specifying a price)” to make it difficult for trading to be established, or “Make trading matching time of trading end time It is possible to deal with unexpected situations by taking measures such as “restrict to one time (the order is accepted, but the transaction establishment process is performed only once)”.

However, the above measures limit the trading opportunities of lively brands (brands with very high trading needs).
For this reason, in the present embodiment, the stocks concentrated in the reserve stock group prepared in advance are immediately saved while online, that is, the stock group is changed. This makes it possible to provide a transaction service up to the maximum performance range of one brand group. In addition, by making the issue group as a separate unit, the deterioration of the response of other issues belonging to the same issue group is avoided. Moreover, as the monitoring means, it is possible only to search the number of records in the requirement DB 720 with the brand key.

  In addition, when any of the stock groups becomes a failure, it is necessary to recover the failed stock group and restart the transaction, but according to the present embodiment, recovery of the stock group unit is possible. It becomes possible quickly. This is because in this embodiment, it is not necessary to wait for the recovery of the faulty brand group. Thereby, it becomes possible to reduce the loss of the transaction opportunity of the exchange user accompanying the transaction interruption time (time required for recovery).

  When changing the stock group, as shown in FIG. 17, the update of the stock group definition database 710 does not solve the stay of the stock A in the assigned stock group processing process 001 (815) before the change. For this reason, the processing of the B brand and C brand in the same brand group processing continues to be delayed, the throughput is not eliminated “instantly”, and the A brand processing newly allocated to the brand group processing process 002 (815) The group A process 001 (815) may overtake the A brand information that is staying and be processed, and the need to “guarantee the order of receipt and perform the process” cannot be met.

  Therefore, in the present embodiment, as shown in FIG. 18, the requirement DB 720 is logically reassigned so that the event group is discarded without processing even if the former charge group receives the event. Yes. Since events can be discarded very quickly, the stagnation can be resolved “immediately”. Further, in the present embodiment, since the requirement registration time in the requirement DB 720 is not updated, it is possible to easily realize “processing with guarantee of the acceptance order for each brand” even after the distribution change.

  Returning to FIG. 14, the active brand temporary allocation process 813 is triggered by a periodic timer or the like, counts the number of unprocessed records for each brand from the requirement DB 720, and stores it in the temporary brand temporary allocation determination DB 770. This is a process of calling the brand group change (brand key designation) process 812 when the set threshold (judgment value) is exceeded. At this time, the replacement issue group designates a reserve issue group.

  The issue group failure temporary allocation process 814 is triggered by a periodic timer or the like, detects from the system log, system journal, etc. that the issue group has become an issue, and selects all issues of the issue issue group. , Process to move to the preliminary issue group. The activation trigger may be any means for accurately detecting a failure such as when called directly by a system call from an OS (Operating System) or CPU monitoring process.

  The order reception database 700 is a database that stores the received order message 600. The order reception database 700 is shown in FIG. The order reception database 700 stores an order reception number and a brand key as key information to be processed by the order registration processing process 817. The order reception number functions as a reception number for a reception notification transmitted to the orderer if a number indicating the order reception order for each brand can be assigned. For example, in order to avoid numbering conflicts by a plurality of order reception processing processes 821, numbers are assigned by orderer codes and brands, and the order registration process process 817 performs numbering in the order of acceptance by brand. You can also

  The requirement database 720 includes a brand group number, a brand key, and a serial number (for example, requirement registration time) indicating a processing order. The requirement database 720 is shown in FIG. Here, when changing the issue group, only the issue group number column is changed, but the issue key and processing sequence are not updated. It is possible to continue processing in the correct order of the reception order. For example, the requirement registration time is automatically set by the DB system when the record is inserted.

  The requirement registration time can be a logically numbered number. This is because it may be in ascending order to keep the processing order. This is effective in the case of a processing system in which the DB system does not automatically set the registration time. In this case, the function name of order registration is “message reception time”. This is because, for example, “number by issuer by orderer” does not follow the order by issue (there is the same number for each orderer).

  However, in the series of processing in the stock group processing process 815, only when the preceding function is limited to one function, if there is a serial number that the preceding function is numbered in the processing order, this number can be adopted. It is. For example, in the requirements from order registration processing to transaction processing, it is more natural to adopt the issue-specific receipt number assigned in the order registration processing as the requirement registration time. This is because the original purpose is to guarantee the order of receipt for each brand and perform processing. In addition, in the requirement for the subsequent function of transaction processing, since a transaction serial number is assigned by brand, this can be adopted.

  Further, from the viewpoint of performance, the requirement DB 720 can be considered to divide the requirement DB 720 itself for each requested function name. As a result, the load on the DB system can also be distributed in units of functions. In this case, the request destination function name column is deleted, and the DB name is divided into “requirement (order registration) DB 720” and “requirement (transaction processing) DB 720”.

  Also, if the request destination function name is used at the time of reference, the DB name is divided. When processing a plurality of function names such as monitoring processing, the search for the number of DBs corresponding to the number of functions is repeatedly performed.

  Further, the processing flag column may be unnecessary as described below. That is, instead of updating with “processed” when the requirement processing is completed, the row is deleted. In addition, the “unprocessed” search condition is not required.

  The brand group definition database 710 is a database that defines the correspondence of brand keys that are processed by the brand group in charge for each brand group. The stock group definition database 710 is shown in FIG. A unique brand group number is set for each brand key for all brand keys. The reserve stock group has zero stocks assigned. The stock group of the normal allocation performs the allocation evenly so that the peak traffic of the day including the prospect and the total number of processing cases are smoothed as much as possible.

  The brand group instruction state database 760 is a database used for exclusive control when a brand group is changed. Further, the brand group instruction state database 760 shows an allocation state for each brand group. The brand group instruction state database 760 is shown in FIG. In FIG. 26, a brand group described as “reserved” is a brand group in which the number of assigned brands is defined as zero in advance. This stock group will be the target of temporary changes. A stock group described as “normal allocation” is a stock group in which the number of stocks assigned is defined as 1 or more in advance. Usually, dozens to hundreds of stocks are assigned. A stock group described as “temporary allocation” is a stock group that was “reserved” at the start, but one or more stocks have been assigned due to a temporary change. A stock group described as “failed” is a stock group in a failure state. In the active brand temporary allocation process 813 and the brand group failure temporary allocation process 814 that are automatically operated, temporary allocation is performed only to the spare group. Stay monitoring (automatic temporary allocation of live stocks) is not performed for temporary stock groups.

The staying brand temporary allocation determination database 770 is a database that sets a staying allowable value (determination value) for each brand key. The staying stock temporary allocation determination database 770 is shown in FIG. The allowable value is set in advance. If retention exceeds this retention limit value, it is judged as an active brand and moved to a spare group by automatic change of the stock group. Improvement ".
This allowable stay value can be determined not only by setting for each brand key but also by setting for each brand key and function. For example, the stay allowable value of the order registration processing process 817 can be set to 100, and the stay allowable value of the transaction processing process 811 can be set to 500.
The stock group to be monitored can be only the stock group of the normal allocation. For example, the issue group that is temporarily allocated has already been assigned 1 issue as an active issue and cannot be changed any more. In addition, there may be a case where it is changed by group designation due to a stock group failure, and temporary allocation is made.

=== Flow of processing ===
Next, the flow of processing in the exchange system according to the present embodiment will be described with reference to FIGS.

<Order acceptance processing>
First, stock order reception processing performed in the order reception server 300 will be described with reference to FIG.

  The order reception processing process 821 receives the order message 600 transmitted from the order input terminal 100 (S4000). Then, the order reception processing process 821 acquires and shares the entire brand group instruction state DB 760 (S4010). Here, if the issue group change process 812 is in the process of change, the process waits until the change process ends. Note that shared acquisition does not wait between shared acquisitions, but waits while another process acquires exclusive. Exclusive acquisition waits while another process acquires exclusive or shared acquisition.

  Subsequently, the order reception processing process 821 generates a brand key from the system code (corresponding to the market code in the first embodiment), product code, brand code, and transaction type described in the order message 600 received in S4000. (S4020). Then, the order reception process 821 searches the brand group definition DB 710 with the brand key generated in S4020, and determines the brand group number to which the brand belongs (S4030). The received order message 600 is stored in the order reception DB 700 (S4040). Here, the brand key acquired in S4020 and the order reception number to be numbered may be "serial number for each order reception process", "number by brand and by orderer", or the like. The key information in the case of “Serial number for each order reception process” is composed of the order reception processing number and the order reception number, and the key information in the case of “number by brand and by orderer” is the brand key and orderer code. And an order reception number. The order reception number does not guarantee the order reception order. The order of acceptance is determined by the request registration time of the requirement DB 720. This is because when you try to determine the order of stocks in the order acceptance process, accurate numbering of “numbers by brand” is required (competition in exclusive processing), and delay processing due to active stocks occurs at the stage of order acceptance processing. This is because there is a possibility that it will end up.

  Subsequently, the order reception processing process 821 stores the requirement processing request event (order registration) in the requirement DB 720 (S4050). “Order registration” is set as the requested function name. However, this is not necessary when the DB is divided for each function. Here, the requirement registration time is automatically set by the DB system, the brand key acquired in S4020 is used as the brand key, and the group number acquired in S4030 is used as the brand group number. The request content includes information that requires order registration for subsequent processing, for example, key information of the order reception DB 700. The processing flag is set to “unprocessed”.

  Then, the order reception processing process 821 transmits a requirement processing request event (order registration) to the brand group number and the request destination function set in S4050 (S4060). The requirement processing request event is shown in FIG. It is assumed that the transmission destination object name (queue name) can be uniquely acquired and generated by a combination of the brand group number and the request destination function name.

<Order registration process>
Next, the order registration process performed in the transaction execution server 200 will be described with reference to FIG.

  First, the order registration process 817 receives a requirement processing request event (order registration) (S5000). Then, the order registration processing process 817 acquires its own brand group number and brand key based on the information described in the requirement processing request event. In addition, when the brand group number of the own brand group is defined for each process, the brand group number in the request event may not be present.

  Subsequently, the order registration processing process 817 searches the brand group instruction state DB 760 for the brand group number of its brand group number and acquires it in common (S5010). Then, the brand group definition DB 710 is searched with the brand key acquired from the requirement processing request event, and the brand group number is obtained (S5020). Note that the processing of S5020 is not always essential. This is a process for deleting a useless event without inducing the requirement DB 720 access load because a useless event remains in the brand group change source. Although the requirement DB 720 may be searched without deleting the event by performing the check, in the case of the change source brand group in which the brand group has already been changed, the search result is zero. When the brand group definition DB 710 is virtually managed on a memory, it can be implemented because the load of the check process is small.

  Next, the order registration processing process 817 determines whether or not the brand group number of the acquired brand group definition DB 710 record is different from the brand group number of its own process (S5030). If the stock group number of the record of the obtained stock group definition DB 710 is different from the stock group number of its own process, since the stock subject to the event has already been changed, the process proceeds to “YES” and the processing by the event is not performed. .

  If the brand group number of the record of the obtained brand group definition DB 710 is the same as the brand group number of its own process, the process proceeds to “NO”, and the order registration process 817 acquires the first one from the requirement DB 720 under the following conditions. (S5040). Here, n events may be acquired and processed, but thereafter, n-1 processed events (empty) are received for the same brand. The performance can be improved by processing n items of the same brand together. The above-mentioned conditions are that the requested function name is order registration, the brand group number is the same as the brand name obtained in S5000, the brand key is the same as the brand key obtained in S5000, the processing flag The first record (or n records) is acquired in the order of requirement registration time.

  Subsequently, the order registration processing process 817 performs order registration processing according to the processing request information part of the record of the acquired requirement DB 720 (S5050). Specifically, according to the order registration request content in the requirement DB 720, the order reception DB 700 is searched for the request key content, and the order registration check is performed. In the case of an error, an error notification creation request is sent to the reception notification creation processing process 816. Further, the receipt number for each brand is assigned, and the receipt number for each brand and the order information are stored in the order / board DB.

  Next, since the order registration processing process 817 has two functions following the order registration processing process 817, two items are registered in the requirement DB 720 for each requested function name (S5060). The number of subsequent processes varies depending on the processing result, that is, whether an error has occurred, whether it was normal, whether a transaction has been completed, whether a transaction has not been completed, and the number of functions such as order registration processing and transaction processing. In the present embodiment, a requirement processing request event (transaction processing) is stored in the requirement DB 720, and a requirement processing request event (acceptance notification creation processing) is also stored. Specifically, when storing a requirement processing request event (transaction processing), “transaction processing” is set as the request destination function name. Note that this is not necessary when the DB is divided for each function. Requirement registration time is automatically set by the DB system, the issue key uses the issue key acquired in S5000, the issue group number uses the group number obtained in S5000, and the request content requires subsequent transaction processing Information such as order / board DB key information is described. The processing flag is set to “unprocessed”. When a requirement processing request event (acceptance notification creation processing) is stored, “acceptance notification creation processing” is set as the request destination function name. Note that this is not necessary when the DB is divided for each function. The requirement registration time is automatically set by the DB system. The brand key acquired in S5000 is used as the brand key, the brand group number acquired in S5000 is used as the brand group number. Enter key information. The processing flag is set to “unprocessed”.

Subsequently, the order registration process 817 transmits a requirement process request event to the request destination function of the same brand group number (S5070). Specifically, a “transaction processing request” event is transmitted to the transaction processing of the same brand group, and a “reception notification creation processing” event is transmitted to the reception notification creation of the same brand group.
Then, the order registration process 817 updates the “processed flag” of the requirement DB 720 that has been processed as described above to “processed” (S5080). Note that there may be n cases according to the number of retrieved items in S5040.

  Although not shown, upon receipt of the requirement processing request event (acceptance notification creation processing), the acceptance notification creation process 816 searches the order / board DB with the request key content according to the content of the acceptance notification creation request in the requirement DB 720. The reception notification message is edited and inserted into the reception notification DB. There is a notification transmission process in charge for each input terminal ID, and a transmission process addressed to the process is called. The notification transmission process of the order reception server 300 is started at the above trigger or timer trigger, and transmits the order reception notification acquired from the reception notification DB to the order input terminal 100 via the network 400. Then, the reception notification creation process 816 updates the “processed flag” of the requirement DB 720 that has been processed as described above to “processed”.

<Transaction processing>
Next, transaction processing performed in the transaction execution server 200 will be described with reference to FIG.

  First, the transaction processing process 811 receives a requirement processing request event (transaction processing) (S6000). Then, the transaction processing process 811 acquires the own brand group number and the brand key based on the information described in the requirement processing request event. In addition, when the brand group number of the own brand group is defined for each process, the brand group number in the request event may not be present.

  Subsequently, the transaction processing process 811 searches the brand group instruction state DB 760 for the brand group number of its brand group number, and obtains it in common (S6010). Then, the brand group definition DB 710 is searched with the brand key acquired from the event, and the brand group number is obtained (S6020). Note that the processing of S6020 is not always essential. This is a process for deleting a useless event without inducing the requirement DB 720 access load because a useless event remains in the brand group change source. Although the requirement DB 720 may be searched without deleting the event by performing the check, in the case of the change source brand group in which the brand group has already been changed, the search result is zero. When the brand group definition DB 710 is virtually managed on a memory, it can be implemented because the load of the check process is small.

  Next, the transaction processing process 811 determines whether or not the brand group number of the acquired brand group definition DB 710 record is different from the brand group number of its own process (S6030). If the stock group number of the record of the obtained stock group definition DB 710 is different from the stock group number of its own process, since the stock subject to the event has already been changed, the process proceeds to “YES” and the processing by the event is not performed. .

  When the stock group number of the record of the obtained stock group definition DB 710 is the same as the stock group number of its own process, the process proceeds to “NO”, and the transaction processing process 811 obtains the first one from the requirement DB 720 under the following conditions ( S6040). Here, n cases may be processed, but after that, n-1 processed events (empty) are received for the same brand. The performance can be improved by processing n items of the same brand together. The above-mentioned conditions are that the requested function name is the transaction process, the brand group number is the same as the own brand group number acquired in S6000, the brand key is the same as the brand key acquired in S6000, the processing flag The first record (n records) is acquired in order of requirement registration time.

  Subsequently, the transaction processing process 811 performs transaction processing according to the processing request information part of the record of the acquired requirement DB 720 (S6050). Specifically, the corresponding record is acquired according to the key information of the order / board DB of the requirement DB 720, and the matching process of the selling order and the buying order is performed. The result of the matching process is stored in an order / board DB (DB managed in order units), a brand DB 730 (database having the latest information for each brand) and a step DB 740 (database in which transaction history is inserted as needed).

  If the contract is not established in S6050, the transaction processing process 811 creates a two-function requirement DB 720 addressed to the market distribution information creation process and the market information creation process. Then, the requirement DB 720 addressed to the three functions of the contract notification creation process is created (S6060). A contract means that a sales transaction is established by matching a selling order and a buying order. When storing a requirement processing request event (market price distribution information creation), the request destination function name is set to “market price distribution information creation”. Note that this is not necessary when the DB is divided for each function. Requirement registration time is automatically set by the DB system, the stock key is the stock key acquired in S6000, the stock group number is the stock group number obtained in S6000, and the requested content is the creation of market distribution information for subsequent processing Information that needs to be processed, for example, key information of the progress DB is described. The processing flag is set to “unprocessed”. When a requirement processing request event (market information creation) is stored, “market information creation” is set as the requested function name. Note that this is not necessary when the DB is divided for each function. Requirement registration time is automatically set by the DB system, the brand key is the brand key obtained in S6000, the brand group number is the brand group number obtained in S6000, and the request content is the process of creating market information in the subsequent process In addition to the key information of the step DB, for example, the key information of the order / board DB is described. The processing flag is set to “unprocessed”. When storing a requirement processing request event (contract notification creation), the request destination function name is set to “contract notification creation”. Note that this is not necessary when the DB is divided for each function. Requirement registration time is automatically set by the DB system, the brand key is the brand key obtained in S6000, the brand group number is the brand group number obtained in S6000, and the request content is a process for creating a contract notification for the subsequent process. Required information, for example, order / board DB key information and the like. The processing flag is set to “unprocessed”.

Subsequently, the transaction processing process 811 transmits a requirement processing request event to the request destination function of the issue group number of the distribution destination (S6070). Specifically, a “market price information creation request” event is sent to the market price information creation process of the same brand group, and a “market price information creation request” event is sent to the market price information creation process of the same brand group. In addition, when the contract is established, in addition to the above, a “contract notification creation request” event is transmitted to the contract notice creation process of the same brand group.
Then, the transaction processing process 811 updates the “processed flag” of the requirement DB 720 that has been processed as described above to “processed” (S6080). There may be n cases according to the number of items taken out in S6040.

  Although not shown, when the market price distribution information creation process receives the requirement processing request event (market price distribution information creation request), it searches and acquires the step DB 740 with the request key contents, edits the market price distribution information message, Insert in the market price distribution information DB. The market distribution processing of the market distribution server transmits the contents of the market distribution information DB at regular intervals.

  Also, when receiving the requirement processing request event (contract notification creation processing), the contract notification creation processing process searches and acquires the order / board DB by request key contents, edits the contract notification message, and inserts it into the contract notification DB. . Further, there is a notification transmission process in charge for each input terminal ID, and the transmission process addressed to the process is called. The notification transmission process of the order reception server 300 is started at the above-mentioned trigger or timer trigger, and transmits the order execution notification acquired from the execution notification DB to the order input terminal 100 via the network.

<Brand group change (brand key designation) processing>
Next, the brand group change (brand key designation) process performed in the transaction execution server 200 will be described with reference to FIG.

  First, the brand group change (brand key designation) process 812 receives a requirement processing request event (brand group change (brand key designation)) (S7000). FIG. 24 shows the event information. Then, the brand group change (brand key designation) process 812 exclusively acquires the brand group instruction state DB 760 with the change source group number and the change destination group number acquired in S7000 (S7010). That is, during the change process, the order reception process and the issue group process belonging to the change source and change destination issue groups are made to wait.

  Subsequently, the brand group change (brand key designation) processing process 812 searches the brand group definition DB 710 using the brand key to be changed acquired in S7000 and acquires the brand group number (S7020). Then, it is checked whether the brand group number of the record of the brand group definition DB 710 acquired in S7020 is the same as the source brand group number (S7030). If they are different, the change target brand key specified in the event has already been changed to any of the brand groups, so an error message is output and the process ends (S7100).

  On the other hand, if they are the same, the brand group number of the record in the brand group definition DB 710 acquired in S7020 is updated with the new brand group (S7040). Then, it is checked whether the allocation status of the record in the brand group designation status DB 760 of the change destination group number acquired in S7010 is spare. In the case of reserve (= the number of issues allocated is zero), the number of issues assigned is 1 or more by the change process, so the allocation state is updated to the temporary allocation (S7050).

  Subsequently, the brand group change (brand key designation) process 812 extracts a record in order to collectively update the contents of the requirement DB 720 in accordance with the brand group change instruction (S7060). Specifically, from the requirement DB, the issue group number is the same as the change source issue group number acquired in S7000, the issue key is the same as the change issue issue key acquired in S7000, and the processing flag is set. Search and acquire unprocessed records in order of requirement registration time.

  As a result, if there is no corresponding record, the process is terminated (S7070). If there is more than one record, only the issue group number is updated with the change issue issue group number in the requirement DB 720 record acquired in S7060. (S7080).

  The brand group change (brand key designation) processing process 812 sends the request event in this process because the request event has not been sent to the destination brand group (S7090). That is, the requirement processing request event is transmitted to the request destination function name of the change destination brand group number. The brand group number at this time is the brand group number after the change.

<Brand group change (Brand group designation) processing>
Next, the brand group change (brand group designation) process performed in the transaction execution server 200 will be described with reference to FIG.

  First, the brand group change (brand group designation) process 812 receives a requirement processing request event (brand group change (brand group designation)) (S8000). FIG. 25 shows the event information. Then, the brand group change (brand group designation) process 812 exclusively acquires the brand group instruction state DB 760 with the change source group number and the change destination group number acquired in S8000 (S8010). That is, during the change process, the order reception process and the issue group process belonging to the change source and change destination issue groups are made to wait.

  Subsequently, the brand group change (brand group designation) process 812 searches the brand group definition DB 710 for a record whose brand group number matches the source brand group (S8020).

  As a result, if there is no corresponding record, an error message is output and the process is terminated (S8110), and if there is a corresponding record, update processing is performed for the number of issues assigned to the change source issue group. (S8040, S8050).

  Then, it is checked whether the allocation status of the record in the brand group designation status DB 760 of the change destination group number acquired in S8010 is spare. In the case of reserve (= the number of issues allocated is zero), the number of issues assigned is 1 or more by the change process, so the allocation state is updated to the temporary allocation (S8060).

  Subsequently, the brand group change (brand group designation) processing process 812 extracts records in order to collectively update the contents of the requirement DB 720 in accordance with the brand group change instruction (S8070). Specifically, a record in which the stock group number is the same as the change source stock group number acquired in S8000 and the processing flag is unprocessed is retrieved from the requirement DB in order of the requirement registration time.

  As a result, if there is no corresponding record, the process is terminated (S8080). If there is more than one record, only the issue group number is updated with the change issue issue group number in the requirement DB 720 record acquired in S8070. (S8090).

  The brand group change (brand group designation) process 812 sends the request event in this process because the request event has not been sent to the brand group to be changed (S8100). That is, the requirement processing request event is transmitted to the request destination function name of the change destination brand group number. The brand group number at this time is the brand group number after the change.

<Temporary allocation process for live stocks>
Next, the active brand temporary allocation process performed in the transaction execution server 200 will be described with reference to FIG. The active stock temporary allocation process is started by a timer for a certain period of time.

  First, the active brand temporary allocation process 813 acquires records in common from the brand group instruction state DB 760 in the order of brand groups (S9000). Then, it is determined whether or not the allocation status of the acquired brand group instruction status record is normal allocation (S9010). It should be noted that a stock group to which stocks are normally assigned is monitored. It is not necessary to monitor for stock groups that are spare or faulty. In addition, since the issue group that is temporarily allocated has already been assigned one issue as an active issue, it cannot be changed any more. There is a case where it is changed by the designation of the group and it becomes temporary allocation. However, since it takes a certain time for the requirement accumulated during the failure, it is excluded from the monitoring target.

  Subsequently, the active brand temporary allocation process 813 counts the record in which the requirement DB 720 has the same brand group number as the brand group number acquired in S9000 and the processing flag is unprocessed for each brand key (S9020). This is to look for booming stocks. When the requirement DB 720 is divided for each function, the requirement DB 720 for each of the functions 1 to n is counted. In addition, the counting method can count for each brand key and for each function to perform the determination process for each function. In this case, the permissible value of the staying issue temporary allocation determination record can be set for each function. Generally, since a transaction processing function with a large load tends to stay, it is also effective to monitor only with this transaction processing function. Generally, a function with a small load does not stay much.

  Subsequently, the active brand temporary allocation process 813 searches the staying brand temporary allocation determination DB 770 with the brand key, giving priority to the brand with the larger count in S9020 (S9030).

  Then, the active brand temporary allocation processing process 813 determines whether or not the stay allowable value of the staying brand temporary allocation determination record is smaller than the count value (S9040). In other words, it is checked whether or not the allowable number of stays set for each brand is exceeded. If the staying allowable value is smaller than the count value, the process proceeds to “YES”, and a spare stock group number is searched for temporarily assigning stocks exceeding the allowable value (= active stocks) to the spare stock group (S9060). ). More specifically, a code whose allocation status is spare is searched from the brand group instruction status DB 760, and the first one is exclusively acquired. If no spare brand group number is found, the process is terminated (S9070).

  When a reserve brand group number is found, a brand group change (brand key designation) is transmitted in order to temporarily allocate active brands to the spare brand group (S9080). That is, in the stock group change (brand key designation) processing request event in FIG. 24, the stock key of S9030 is the stock key to be changed, the stock group number of S9000 is the stock group number of the change source, and the stock of S9060 is the stock group number of the change destination Each group number is set, and a brand group change (brand key designation) event is transmitted to the brand group change (brand key designation) process.

  Then, the active brand temporary allocation process 813 repeats the active brand check for the number of corresponding brand keys in the requirement DB 720 (S9050). Further, the above process is repeated for the number of stock groups (S9090).

<Typical issue group failure allocation process>
Next, the issue group failure temporary allocation process performed in the transaction execution server 200 will be described with reference to FIG.

  First, the brand group fault temporary allocation process 814 scans for a message reporting a brand group fault from the continuation of the system log monitored at the previous activation (S10000). The detection method can be any method. It is also possible to receive a notification from the CPU, OS, etc., or to monitor the system log.

  Subsequently, the stock group failure temporary allocation process 814 checks whether or not there is a message indicating the occurrence of the stock group failure (S10010). Here, it is assumed that the symbol group number that has failed from the failure message can be acquired. If there is no message, the process is terminated (S10010).

If there is a message, the failure brand group number is acquired from the output content of the failure message (S10020).
Then, the brand group instruction state DB 760 is exclusively acquired with the brand group number obtained in S10020 (S10030). Furthermore, the allocation state of the stock group instruction state record acquired in S10020 is updated during failure (S10040).

  Then, the brand group failure temporary allocation process 814 checks whether or not the allocation status before the update of the brand group instruction status record acquired in S10020 is preliminary (S10050). In the case of a reserve, since the number of assigned brands is zero, the subsequent processing is terminated (S10050).

If it is not a reserve, in order to move all issues belonging to the failed issue group to an available issue group (= reserve issue group), a record whose assignment status is reserve is searched from the issue group indication state DB 760, and the first 1 Acquire exclusive records (S10060). Then, the presence / absence of a spare brand group is checked (S10070).
As a result, if there is no spare brand group (= all assigned), the process is terminated (S10070).

 On the other hand, if there is a reserve brand group, a brand group change (brand group designation) is transmitted in order to temporarily allocate all brands of the faulty brand group to the spare brand group (S10080). Specifically, in the issue group change (issue group designation) processing request event shown in FIG. 25, set the issue group number of S10020 as the change source issue group number and the issue group number of S10060 as the change issue issue group number, A brand group change (brand group designation) event is sent to the brand group change (brand group designation) process.

=== Third embodiment ===
The second embodiment may be a third embodiment as described below.
The third embodiment differs from the second embodiment in order registration processing and transaction processing. The order registration process and transaction process according to the third embodiment are shown in FIGS. 38 and 39, respectively. According to the third embodiment, it is possible to further increase the processing speed.

First, the order registration process will be described with reference to FIG.
First, the order registration process 817 receives a requirement processing request event (order registration) (S11010). In the present embodiment, the requirement processing request event (order registration) may not include information such as “brand group number” and “brand key” as shown in FIG. This is because the stock group number is retained as a process definition at the time of startup, and the stock key is not used in the search. In the present embodiment, the requirement search is performed only by the brand group number. Therefore, when the issue group is changed, the change source group receives an invalid event, but the search result in the requirement DB 720 is zero, and there is no actual harm.

  Subsequently, the order registration processing process 817 acquires the brand group instruction state DB 760 in common (S11020). Then, the order registration process 817 acquires the first one from the requirement DB 720 shown in FIG. 35 under the following conditions (S11030). Here, n events may be acquired and processed, but thereafter, n-1 processed events (empty) are received for the same brand. The performance can be improved by processing n items of the same brand together. Here, the condition described above is to acquire the first record (or n records) in the order of requirement registration time, with the record group number being the same as the own brand group number and the processing flag being unprocessed. The order registration process 817 searches whether there is a requirement for own charge when an event occurs. There is no change check with the stock key. This is because stock group changes do not occur frequently.

  Subsequently, the order registration processing process 817 performs order registration processing according to the processing request information part of the record of the acquired requirement DB 720 (S11040). Specifically, according to the order registration request content in the requirement DB 720, the order reception DB 700 is searched for the request key content, and the order registration check is performed. In the case of an error, an error notification creation request is sent to the reception notification creation processing process 816. Further, the receipt number for each brand is assigned, and the receipt number for each brand and the order information are stored in the order / board DB.

  Next, since the order registration processing process 817 has two functions following the order registration processing process 817, two items are registered in the requirement DB 720 for each requested function name (S11050). The number of subsequent processes differs depending on the processing result, that is, whether an error has occurred, whether it was normal, whether a transaction has been completed, whether a transaction has not been completed, and other functions such as order registration processing and transaction processing. In the present embodiment, a requirement processing request event (transaction processing) is stored in the requirement DB 720, and a requirement processing request event (acceptance notification creation processing) is also stored.

  Subsequently, the order registration processing process 817 transmits a requirement processing request event to the request destination function of the same brand group number (S11060). Specifically, a “transaction processing request” event is transmitted to the transaction processing of the same brand group, and a “reception notification creation processing” event is transmitted to the reception notification creation of the same brand group.

  Then, the order registration process 817 updates the “processed flag” in the requirement DB 720 that has been processed as described above to “processed” (S11070). Note that there may be n cases in accordance with the number of items taken out in S11030.

Next, transaction processing will be described with reference to FIG.
First, the transaction processing process 811 receives a requirement processing request event (transaction processing) (S12010). The requirement processing request event (transaction processing) in the present embodiment includes “brand key” as shown in FIG. 37, but does not need to include “brand group number”. This is because the stock group number is retained from the time of startup as its own process definition.

  Subsequently, the transaction processing process 811 searches the brand group instruction state DB 760 for the brand group number of its brand group number, and obtains it in common (S12020). Then, the brand group definition DB 710 is searched with the brand key acquired from the event, and the brand group number is acquired (S12030). Note that the processing of S12030 is not always essential. This is a process for deleting a useless event without inducing the requirement DB 720 access load because a useless event remains in the brand group change source. Although the requirement DB 720 may be searched without deleting the event by performing the check, in the case of the change source brand group in which the brand group has already been changed, the search result is zero. When the brand group definition DB 710 is virtually managed on a memory, it can be implemented because the load of the check process is small.

  Next, the transaction processing process 811 determines whether or not the brand group number of the acquired brand group definition DB 710 record is different from the brand group number of its own process (S12040). If the stock group number of the record of the obtained stock group definition DB 710 is different from the stock group number of its own process, since the stock subject to the event has already been changed, the process proceeds to “YES” and the processing by the event is not performed. .

  When the stock group number of the record of the obtained stock group definition DB 710 is the same as the stock group number of its own process, the process proceeds to “NO”, and the transaction processing process 811 starts from the requirement DB 720 shown in FIG. Is acquired (S12050). Here, n cases may be processed, but after that, n-1 processed events (empty) are received for the same brand. The performance can be improved by processing n items of the same brand together. Here, the above-described condition is that the record having the same brand key as the brand key acquired in S12010 and the processing flag being unprocessed is acquired in the first one (n) in order of requirement registration time.

  Subsequently, the transaction processing process 811 performs transaction processing according to the processing request information part of the record of the acquired requirement DB 720 (S12060). Specifically, the corresponding record is acquired according to the key information of the order / board DB of the requirement DB 720, and the matching process of the selling order and the buying order is performed. The result of the matching process is stored in the order / board DB, brand DB 730, and step DB 740.

  If the contract is not established in S12060, the transaction processing process 811 creates a two-function requirement DB 720 addressed to the market distribution information creation process and the market information creation process. Then, the requirement DB 720 addressed to the three functions of the contract notification creation process is created (S12070).

Subsequently, the transaction processing process 811 transmits a requirement processing request event to the request destination function of the brand group number of the distribution destination (S12080). Specifically, a “market price information creation request” event is sent to the market price information creation process of the same brand group, and a “market price information creation request” event is sent to the market price information creation process of the same brand group. In addition, when the contract is established, in addition to the above, a “contract notification creation request” event is transmitted to the contract notice creation process of the same brand group.
Then, the transaction processing process 811 updates the “processed flag” of the requirement DB 720 that has been processed as described above to “processed” (S12090). Note that there may be n cases according to the number of retrievals in S12050.

  As described above, according to each embodiment, the transaction processing of various commodities such as stocks can be processed in parallel for each brand group, and the transaction processing of stocks etc. can be realized quickly and fairly, and the transaction can be stopped. Load distribution and failure avoidance can be achieved. This makes it possible to realize highly reliable and high-speed transaction processing for stocks and the like. In other words, even in the case of trading of stocks, even if there is a flood of orders for a certain stock due to sudden news, etc., and the processing load on a certain stock group increases, the order of trading is not stopped. It is possible to quickly move the stock to another stock group while protecting the system and to distribute the load among the stock groups. In addition, even if a computer system fails during trading of stocks, etc., the trading of each stock classified as a stock group affected by the failure is stopped by a stock group that is not affected by the failure. It is possible to prevent the transaction from being affected by moving quickly without observing the transaction order.

  Although the best mode for carrying out the invention has been described above, the above embodiment is intended to facilitate understanding of the present invention and is not intended to limit the present invention. The present invention can be changed and improved without departing from the gist thereof, and the present invention includes equivalents thereof.

It is a figure showing the whole exchange system composition. It is a figure which shows the structure of a transaction execution server, an order reception server, and an order input terminal. It is a figure which shows the memory | storage device of an order input terminal. It is a figure which shows the memory | storage device of a transaction execution server. It is a figure which shows the memory | storage device of an order reception server. It is a figure which shows an order reception database. It is a figure which shows a brand group definition database. It is a figure which shows a requirements database. It is a figure which shows a transaction processing allocation database. It is a figure which shows an order message | telegram. It is a flowchart which shows the flow of an order reception process. It is a flowchart which shows the flow of transaction processing. It is a flowchart which shows the flow of a brand group change process. It is a figure showing the whole exchange system composition. It is a figure for demonstrating an order reception process and a brand group process. It is a figure for demonstrating an order reception process and a brand group process. It is a figure for demonstrating an order reception process and a brand group process. It is a figure for demonstrating an order reception process and a brand group process. It is a figure which shows an order message | telegram. It is a figure which shows an order reception database. It is a figure which shows a brand group definition database. It is a figure which shows a requirements database. It is a figure which shows a requirement process request event. It is a figure which shows a brand group change (brand designation) processing request event. It is a figure which shows a brand group change (brand group designation) processing request event. It is a figure which shows a brand group instruction | indication state database. It is a figure which shows a retention brand temporary allocation determination database. It is a flowchart which shows the flow of an order reception process. It is a flowchart which shows the flow of an order registration process. It is a flowchart which shows the flow of transaction processing. It is a flowchart which shows the flow of a brand group change (brand key specification) process. It is a flowchart which shows the flow of a brand group change (brand group designation) process. It is a flowchart which shows the flow of an active brand temporary allocation process. It is a flowchart which shows the flow of a brand group failure temporary allocation process. It is a figure which shows a requirements database. It is a figure which shows a requirements database. It is a figure which shows a requirement process request event. It is a flowchart which shows the flow of an order registration process. It is a flowchart which shows the flow of transaction processing.

Explanation of symbols

DESCRIPTION OF SYMBOLS 100 Order input terminal 200 Transaction execution server 300 Order reception server 400 Network 500 Recording medium 600 Order message 700 Order reception database 710 Brand group definition database 720 Requirements database 730 Brand database 740 Step database 750 Transaction processing allocation database 760 Brand group instruction state database 770 Residual issue temporary allocation determination database 800 Order input terminal control program 810 Trade execution server control program 811 Transaction processing 812 Operation management 813 Monitoring 814 Failure detection 815 Brand group processing 816 Reception notification creation processing 817 Order registration processing 820 Order reception server control program 821 Order Reception processing

Claims (5)

A stock group management table for associating each identifier of a plurality of stock groups obtained by classifying each stock subject to be traded in the market with information indicating each stock subject to be traded into each stock group;
A transaction request receiving unit for receiving a plurality of transaction requests in which information indicating a brand to be traded is described;
Each received transaction request is stored in association with an identifier of each brand group associated with information indicating each brand of the transaction target described in each trade request and creation time information of the record of the trade request. A transaction request storage unit to
A plurality of transaction processing units that receive a transaction processing notification from the transaction request receiving unit, and that read out each transaction request stored in the transaction request storage unit for each brand group in the stored order, and perform transaction processing; ,
A read management table that stores an identifier of a brand group that identifies a transaction request that each transaction processing unit reads from the transaction request storage unit in association with an identifier of each transaction processing unit,
Corresponding to the information indicating the brand with the trading target among the items of the brand group management table when changing the brand group in which the brand with trading target is classified from the first brand group to the second brand group regarding the identifier with its dependent stocks groups only, with changing from identifier of the first brand group identifier of the second brand group, shows the stocks with the transaction object before Symbol transaction request storage unit The identifier of the first brand group is changed from the identifier of the first brand group to the identifier of the second brand group only for the identifier of each brand group associated with each trade request in which information is described, and the trade request storage A brand group update processing unit that does not update the creation time information of the record of the transaction request in the unit ,
The transaction processing unit related to the first issue group discards the communication without executing the corresponding transaction process when receiving the transaction process notification of the first issue group from the transaction request receiving unit. ,
An information processing apparatus characterized by that. A reception number comparison unit that compares the number of transaction requests received per unit time with a judgment value for each stock group;
With
The first stock group is a stock group in which the number of transaction requests received per unit time exceeds a judgment value.
The information processing apparatus according to claim 1. An anomaly detector that detects an anomaly of each transaction processing unit;
With
The first brand group is a brand group identified by an identifier associated with an identifier of a transaction processing unit in which an abnormality is detected by the abnormality detection unit in the read management table.
The information processing apparatus according to claim 1. A stock group management table for associating each identifier of a plurality of stock groups obtained by classifying each stock subject to be traded in the market with information indicating each stock subject to be traded into each stock group;
A transaction request receiving unit for receiving a plurality of transaction requests in which information indicating a brand to be traded is described;
Each received transaction request is stored in association with an identifier of each brand group associated with information indicating each brand of the transaction target described in each trade request and creation time information of the record of the trade request. A transaction request storage unit to
A plurality of transaction processing units that receive a transaction processing notification from the transaction request receiving unit, and that read out each transaction request stored in the transaction request storage unit for each brand group in the stored order, and perform transaction processing; ,
A read management table that stores an identifier of a brand group that identifies a transaction request that each transaction processing unit reads from the transaction request storage unit in association with an identifier of each transaction processing unit,
A method for controlling an information processing apparatus comprising:
Corresponding to the information indicating the brand with the trading target among the items of the brand group management table when changing the brand group in which the brand with trading target is classified from the first brand group to the second brand group regarding the identifier with its dependent stocks groups only, with changing from identifier of the first brand group identifier of the second brand group, shows the stocks with the transaction object before Symbol transaction request storage unit The identifier of the first brand group is changed from the identifier of the first brand group to the identifier of the second brand group only for the identifier of each brand group associated with each trade request in which information is described, and the trade request storage Do not update the creation time information of the transaction request record in the department,
In the transaction processing unit related to the first issue group, when the transaction request for the first issue group is received from the transaction request receiving unit, the contact is discarded without executing the transaction process. A method for controlling the information processing apparatus. A stock group management table for associating each identifier of a plurality of stock groups obtained by classifying each stock subject to be traded in the market with information indicating each stock subject to be traded into each stock group;
A transaction request receiving unit for receiving a plurality of transaction requests in which information indicating a brand to be traded is described;
Each received transaction request is stored in association with an identifier of each brand group associated with information indicating each brand of the transaction target described in each trade request and creation time information of the record of the trade request. A transaction request storage unit to
A plurality of transaction processing units that receive a transaction processing notification from the transaction request receiving unit, and that read out each transaction request stored in the transaction request storage unit for each brand group in the stored order, and perform transaction processing; ,
A read management table that stores an identifier of a brand group that identifies a transaction request that each transaction processing unit reads from the transaction request storage unit in association with an identifier of each transaction processing unit,
In an information processing apparatus comprising
Corresponding to the information indicating the brand with the trading target among the items of the brand group management table when changing the brand group in which the brand with trading target is classified from the first brand group to the second brand group regarding the identifier with its dependent stocks groups only, with changing from identifier of the first brand group identifier of the second brand group, shows the stocks with the transaction object before Symbol transaction request storage unit The identifier of the first brand group is changed from the identifier of the first brand group to the identifier of the second brand group only for the identifier of each brand group associated with each trade request in which information is described, and the trade request storage A procedure not to update the creation time information of the record of the transaction request in the department;
In the transaction processing unit relating to the first issue group, when a transaction processing notification of the first issue group is received from the transaction request receiving unit, a procedure for discarding the communication without executing the transaction processing is executed. Program to let you.