JP2007226584A - Transaction system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To solve the problem that unprocessed subjects are accumulated in issuing a processing request (timed processing request to be expired after a prescribed time) from a certain device to trigger processing. <P>SOLUTION: When there is no information about a processing request to itself but there is the processing request actually, the processing request is issued to itself to start the processing. In this case, this invention includes separately handling the information about the processing request and requirement information required for carrying out the processing corresponding to this request, and it can be determined from the presence of the requirement information whether there is the processing request actually. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a technique for realizing a predetermined operation including a transaction of a product including securities such as stocks. Among them, the present invention relates to trading, in particular, a securities trading system used in an exchange called a securities market, a method thereof, and a program therefor.

  2. Description of the Related Art Conventionally, when executing a business such as a stock transaction, it has been executed to realize a business by linking a plurality of processing devices. In order to execute such processing, processing is performed using a so-called queue. For example, Patent Document 1 discloses the following configuration. The purpose of the business process tracking system is to enable the tracking of the flow of business processes consisting of multiple applications performed across different business systems without changing the existing system. In order to achieve this object, in Patent Document 1, the event management apparatus 1 collects event data extracted by the event extraction units 32 to 52 of the business systems A3 to C5 based on the event extraction definition, and the event queue 12 To queue. The event association unit 13 compiles event data into business data units, associates the business data, and accumulates them in the event management DB 14. When a search condition is input from the user terminal 6, the output unit 16 searches the event management DB 14 according to the search condition, and outputs and displays the relation between the business data to the user terminal 6 in a tree format.

JP 2005-115494 A

  However, Patent Document 1 is intended for a workflow and how to grasp (track) a business process. That is, in Patent Document 1, no particular consideration is given to how recovery is performed when a process to be executed by each processing apparatus is not performed. For this reason, in Patent Document 1, when the processing in the processing device stops, the predetermined work cannot be efficiently recovered. In particular, there is a problem that unprocessed matters are accumulated when a processing request is issued from a certain device (the one that expires at a predetermined time in a timed expression) and the processing is executed using that as a trigger. Occurs. Furthermore, when unprocessed matters are accumulated in this way, not only hardware resources such as storage devices are wasted, but also the system including these hardware resources is stopped, and the business including transactions itself is stopped. It also happens.

  Therefore, in the present invention, when there is no information related to the processing request for itself and there is actually an item to be processed (case, requirement information), the request information is issued to itself and the processing is started. Here, in the present invention, the information regarding the processing request and the corresponding requirement information necessary for executing the processing are included separately, and there is what should be processed as an entity depending on the presence or absence of the requirement information. It may be judged.

More specifically, the present invention is configured as follows.
In a transaction system, each of which is a plurality of transaction terminals belonging to any of a plurality of groups, connected to a transaction terminal that transmits a transaction request, and configured from a plurality of processing devices to perform a securities transaction process corresponding to the transaction request The plurality of processing devices include a first processing device that issues a processing request for executing at least a part of the securities transaction processing and that may become ineffective after issuance, and the request information. Requirement information for executing a process to be executed by the process request corresponding to the process request by issuing the process request, including a second processing apparatus that executes a process according to the request Is stored in the requirement database, and the second processing device checks whether there is an issued processing request. (1) If there is the processing request, the corresponding requirement information is stored in the requirement data. (2) If there is no processing request, search the requirement database and search for unprocessed requirement information among the processing to be executed by itself. If there is unprocessed requirement information, it issues request information corresponding to the existence of unprocessed requirement information to itself, receives the request information, and acquires the corresponding requirement information from the requirement database. The corresponding process is executed. Here, the processing request whose effect disappears after a certain period after issuance includes a non-permanent message that is not recovered in the event of a machine failure or the like. Further, it may be effective or disappear after a certain period.

  Here, the confirmation of the presence / absence of the issued processing request includes the confirmation of the presence / absence of a valid processing request. For example, it also includes detecting that an issued processing request is invalidated (for example, time-out including disappearance of effectiveness and disappearance of itself). Further, the first processing device writes this processing request in a predetermined database (accessible from each processing device). This database may be a requirement database. Further, the confirmation of the presence or absence of a processing request from the second processing apparatus is executed by accessing the database. At this time, a flag indicating processing / non-processing may be provided in the requirement information, and the presence / absence confirmation may be executed using this content. However, the processing request may be transmitted to the second processing apparatus, and the requirement information may be stored in the requirement database.

  The request information issued by the second processing apparatus may be a “pseudo” processing request. That is, the content is the same item as the processing request, and the target requirement information (processing target) is input according to the requirement information stored in the requirement database. That is, out of the requirement information stored in the requirement database that should be processed by itself, unprocessed requirement information is extracted, and identification information corresponding to the requirement information is written. Here, the time stamp function may be used to maintain the order. In other words, the extracted requirement information includes information indicating the request time recorded by the time stamp function, and the order information is controlled using this information.

  Further, the present invention includes issuing the request information when it is detected that time-out (invalidation) has been detected.

  In the above, the following processing is also included in the present invention. When there is an unprocessed processing request (for example, when invalidation such as a timeout is detected), the second processing device counts the number of the unprocessed requirement information and executes the corresponding processing When the corresponding requirement information is acquired, the number of cases is decremented by 1, and the request information issuance to itself can be repeated until the number of cases indicates 0.

  Here, the number of cases may be as follows. First, information indicating whether or not it has been processed is included in the requirement information, and unprocessed requirement information that should be processed by itself is counted using identification information or the like. More specifically, it is as follows. If "group code" is used as the search condition, the total is calculated using the "group code (identifier that identifies the group)" assigned to the process. "Is used as a search condition, and is aggregated in units of" keys ", and the number of cases is set in the retransmission MQ (request information). (In the case of “key”, the MQ sends for the key types that have unprocessed requirements). Here, the number of unprocessed cases may be counted from the contents of the requirement database and recorded (that is, the recorded contents are regarded as the number of unprocessed cases).

  The requirement information can be realized by counting the number of remaining requirement information as a configuration in which processed information is deleted and unprocessed information is left in the requirement database.

  Further, in the above configuration, the present invention also includes that at least one of the processing request and the request information is information whose own effect disappears (invalidation, timeout) after a predetermined time. Further, the processing request and the request information may be a transfer queue.

  Furthermore, the present invention is applied to a configuration in which a so-called transaction (a plurality of transaction requests) is divided into predetermined units and each processing (including sub-operation units for processing) is executed in parallel processing. To include.

  According to the present invention, it is possible to more easily realize processing recovery.

  Embodiments of the present invention will be described with reference to the drawings. In the present embodiment, a transaction of securities (stocks) will be described as an example. However, the present invention is not limited to this (application to other business operations is also included in the present invention).

First, the basic contents of this embodiment will be described.
(1) Normally, from a contact source process (for example, the accepting device 2 in FIGS. 1 and 2) to a contact process (for example, the transaction processing device 3 in FIGS. Send transfer queue "). Here, the destination is an apparatus, that is, hardware, but in this embodiment, hardware may be different or the same. It suffices if a requirement database registration and a processing request (MQ) can be transmitted from a certain process (processing program) to the process request destination process. For example, the process of “order reception” has the number of terminal groups, and the process of “transaction processing control 1” operates by the number of brand groups. “Transaction processing control 1” is attached to “brand group” which is a set of a plurality of brand keys. One process is specified by a combination of a function name “transaction processing control 1” and a brand group. The server and the group may be one-to-one, or a plurality of groups may be arranged on the server.
(2) Upon receiving the MQ, the contact process acquires one requirement information (record) from the requirement DB corresponding to the MQ (SELECT). Here, this acquisition method is performed by using an identifier (for example, a group code) for identifying (a) its own “group” (or itself) (MQ and requirement information each include a group code) And (b) using an identifier for identifying a brand to be traded (MQ and requirement information include an identifier for identifying a brand, respectively). The requirement information includes time information of the time when the contact source process issued a processing request (or is a predetermined process such as transmission and may be a process for the requirement information) using a time stamp function. Include it. Then, the order of acquisition is determined according to the order of the time information. For example, acquisition is performed in order of oldness.

  Here, when MQ is invalidated (timeout), etc. (or when invalidation is detected), the contact process searches the requirements database and issues (for example, requirement information) Detect if there is any. In this detection, a search or the like is performed in the same manner as the method described in (2) above. In more detail, it is as follows. The “group code” and “key” of the processing request destination are assigned to both the requirement database and the processing request (MQ). When the contact process acquires a message (MQ) with MQGET, it checks that it is a message for its own process, and then uses the same "group code" or "key" and is unprocessed as a search condition. The requirement record with the oldest registration time is searched from the requirement database.

  MQ is a trigger for searching the requirement database. That is, the MQ does not have to indicate information “what to do”. “What to do” is registered in the requirements database. In the requirement database, for example, information specifying the corresponding order data (recorded in the order reception database, etc.) is set as “what to do”, so the order reception database is processed in the order in which the requirement database is acquired. (E.g., ensuring the order of order processing within the same stock required by the exchange).

  (3) Next, in the contact address process, a program for executing the process corresponding to the acquired requirement information is started and the process is executed. And it notifies to the next process (for example, contract processing device).

Next, FIG. 1 shows a system configuration diagram according to the present embodiment. Each computer is connected to each other via a network. Each computer has a processing device such as a memory, a storage device including a hard disk, and a CPU, and the processing device executes information processing according to a program stored in the storage device. As shown in FIG. 1, the system in the present embodiment includes a transaction terminal 1, a reception device 2, a transaction processing device 3, a contract processing device 4, and a storage device group 5 in which information related to transactions is stored. Each of these structural requirements is composed of a plurality of components. (1) Transaction terminal 1 may be a group of a plurality of transaction terminals. (2) In addition, acceptance device 2, transaction processing device 3. The contract processing device 4 is configured as an integrated server device as hardware, and each may be configured as software having the function. In the case of (2), the reception device 2 and the transaction processing device 3 may be integrated, and the transaction processing device 3 and the contract processing device 4 may be integrated. In the present embodiment, as shown in FIG. 2, an example in which the contract processing device 4 and the transaction processing device 3 are integrated will be described. 1 and 2, each receiving device 2 (21, 22) is associated with each group of transaction terminals (such as a securities company). In addition, each transaction processing device 3 and each contract processing device 4 (or processing devices 31 and 32 in which these are integrated) are associated with each brand to be processed, and processing for transaction requests of this correspondence relationship Execute. This correspondence may be included in software instead of the device, that is, hardware. Furthermore, this correspondence may be changed dynamically based on conditions such as the transaction volume. In other words, when a certain number (volume) of transaction requests from a group or a certain brand is (increased), a given device (for example, the same type of device with the least number of transaction requests, computer resources) You may make it perform the process of the group (or brand). In addition, in the same type of device, it is detected whether the relationship between transaction requests (or the amount of calculation associated therewith) satisfies a certain relationship (difference is greater than a threshold or a predetermined relationship such as 1:10). Thus, changing the correspondence (changing a device with a small number of transaction requests to a device with a large number of transaction requests) is also included in the present embodiment. Thus, the following effects can be achieved by combining with the decentralization processing.
(1) “Processing order guarantee”, which is a business requirement, can be performed. Since the sub-tasks are divided in a flow like “terminal group: n → stock group: m → terminal group: n”, securing the processing order is a problem, but the oldest unprocessed in the requirement DB Therefore, the processing order is guaranteed (stock group unit) (processing requests are generated from n terminal groups for the requirement DB of the brand group 1).
(2) It becomes possible to use only the DBMS as the failure recovery target resource. In XA linkage (two-phase commit) with recovery target resources in both the transaction monitor and the DBMS, the commit processing performance becomes long, so the recovery target resource is only the DBMS and non-XA linkage is used to ensure commit performance. Is possible. Needless to say, the present invention is applicable even in the case of XA cooperation.
(3) It is possible to ensure the order during recovery. With the function (1) (processing is performed in order from the oldest unprocessed one in the requirement database), it is possible to ensure the order even after failure recovery.
It should be noted that the present invention also includes not being distributed to sub-business units.

  Next, the processing flow of the present embodiment will be described with reference to FIG. First, as an initial process, in step 100, a process is started. Here, including the following steps, processing in the transaction processing device 3 will be described as an example. For example, a program used in this apparatus is started.

  Next, in step 101, MQGET, that is, a processing request is acquired. The MQ is transmitted from the accepting device 2 and is stored in a predetermined storage device. If the MQ storage device does not exist, the MQGET operation times out. Here, the MQ may be controlled to be invalidated as a timeout when a predetermined time is reached. The predetermined time may be set to time out in a shorter time when the process is started than in other cases. By setting in this way, it is possible to prevent the stored MQ from disappearing due to system switching or the like. Note that the time of starting includes accessing a storage device for the first time after starting.

  Next, in step 102, it is detected whether MQGET (or MQ) has timed out. When the time-out has occurred (when detected), the process proceeds to step 103 to perform MQ transmission to itself. Here, MQ may be a trigger for searching the requirement database. The information “what to do” may not be shown. “What to do” is registered in the requirements database. In the requirement database, information specifying, for example, corresponding order data (recorded in the order receiving database) is set as “what to do”. In this way, it may be a trigger (and more suitable if it is invalidated under a predetermined condition), and may be other than MQ.

Details of step 103 will be described with reference to FIG.
First, in step 1031, the number of unprocessed matters (that is, requirement information) is counted from the requirement database shown in FIG. That is, among the requirement information, the number of requirement information of information (which may be identification information of the transaction processing device) indicating that the transaction processing device is to be processed is extracted. Count. First, the requirement information of the information indicating that the transaction processing device should be processed (which may be the identification information of the transaction processing device) is extracted, and the processed flag is detected from among them. Also good.

  Next, in step 1032, it is determined whether or not there is an unprocessed matter in step 1031. If there is no result, the process proceeds to step 115 as it is, and this step 103 is terminated. If there is, the process proceeds to Step 1033.

  In step 1033, the MQ to be transmitted to itself, that is, the retransmission MQ is edited (generated). As described above, since MQ may be a trigger, information identifying itself (transaction processing apparatus) may be included. However, more preferably, MQ may include key information such as a group code for identifying a group to which the transaction processing apparatus belongs (or the transaction processing apparatus itself) or processing time such as registration of corresponding requirement information. Here, the number of MQs equal to or less than the number of unprocessed cases counted in step 1031 is generated. More preferably, it may be less than the number of unprocessed cases. This is to prevent an increase in transactions and overflow of the queue by this retransmission MQ, and the number thereof may be appropriately determined in consideration of these.

  Then, the process proceeds to step 1034, and the retransmission MQ is transmitted to the own process (transaction processing apparatus). Then, this process is terminated (step 1035), and the process proceeds to step 115.

  Next, the process proceeds to step 115, where the transaction is settled, and the process proceeds to step 104. In step 104, as in step 101, a processing request is acquired. In step 105, as in step 102, it is detected whether a timeout has occurred. The timeout value here may be longer than that in step 102. As a result, if a timeout occurs, the process proceeds to step 106 and the same processing as in step 103 is executed.

  Next, a case where it is determined in step 102 or step 105 that there is no timeout will be described. If so, the process proceeds to step 107. In step 107, the MQ transmitted to itself including the MQ retransmitted in steps 103 and 106 is acquired from the storage device. Here, the acquired MQ is deleted from the storage device.

  Next, in step 108, corresponding to the acquisition of MQ, one piece of requirement information is acquired from the requirement database (requirement DB). Here, the acquisition method of one requirement information is performed using the key information included in the MQ and the contents (key information, time information (not shown)) of the requirement database shown in FIG. That is, among the requirement information included in the requirement information, the requirement information whose processed flag is unprocessed and whose registration is the oldest in the transaction processing device is selected (this information is included in key information and UAP information. Is possible). In this way, if the requirement information cannot be selected, the process proceeds to step 115, and if selected, the process proceeds to step 110.

  Next, in step 110, transaction processing corresponding to the selected requirement information is executed according to the application program using the requirement information.

  After the completion of step 110 or in parallel with step 110, the processes of steps 111 to 114 are executed. In step 111, the number of retransmission MQs after step 100 is counted. This is realized by including the number of cases in the MQ and counting it. In addition, it may be performed by counting and recording each time it is issued. It is feasible. As a result, when the number of retransmission MQ is 0, the process proceeds to step 115. If it is not 0, the process proceeds to step 112.

  In step 112, calculation is performed so as to subtract 1 from the number of retransmissions from the storage device in which the number of retransmissions MQ is stored. Then, it is detected whether a predetermined time has passed (step 113). If the result is affirmative, the process proceeds to step 114, and retransmission processing is executed in the same manner as in step 103. If it is not detected in step 113 that a certain time has elapsed, the process proceeds to step 115. Here, the confirmation of whether or not a certain time has passed is executed to perform monitoring in order to cope with a failure or queue overflow of some devices. Here, the number of retransmissions is stored in the storage device, but may be configured as follows. Although temporarily stored in a memory or the like, the number of retransmissions is included in the retransmitted MQ. That is, in step 112, the MQ including the number of retransmissions obtained by subtracting 1 from the number of retransmissions counted in step 111 is retransmitted.

  According to the processing of the above embodiment, the effects shown in FIG. 6 and the following can be achieved. As long as the requirement DB can be registered, business processing can be continued in the order of requirement registration. In addition, processing can be performed without significant delay by MQ retransmission processing. In particular, it is possible to cope with the following cases. (1) A case in which the MQ queue overflow of the processing request source server occurs due to large-scale order input from some participants (such as securities companies), (2) Processing due to orders concentrated on a specific issue, etc. Requested MQ queue overflow, (3) MQ lost due to processing request destination server down, etc. (4) MQ not deleted due to processing request destination process down, resulting in MQ When the queue overflow occurred.

By handling MQ as a trigger as in this embodiment,
・ Process the orders stored in the database according to the principle of time priority. ・ It is possible to increase the response speed and the number of unit time processing.

In the recovery process according to this embodiment,
・ Even if MQ is partially lost due to concentration of orders on specific issues, it is possible to process orders without delay as much as possible. Note that this embodiment is effective in the case of including MQ (not subject to recovery in the event of a failure) (permanent MQ may be mixed). For example, the order reception process is arranged in a plurality of communication servers. In this case, when an MQ transfer delay or failure occurs in the middle of a server, the ordering transaction participant of the corresponding order may be behind the other transaction participants, It is possible to eliminate the risk of suffering disadvantages due to changes in the state.

It is a system configuration figure (1) in this embodiment. It is a system configuration figure (2) in this embodiment. It is a flowchart which shows the content of the process in this Embodiment. In FIG. 3, it is a flowchart explaining the detail of a resending process. Always). It is a figure which shows a requirements database. (Normal end). It is a figure explaining the effect and process outline | summary of this Embodiment.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 ... Transaction terminal, 2 ... Reception apparatus, 3 ... Transaction processing apparatus, 4 ... Contract processing apparatus

Claims (6)

In a transaction system, each of which is a plurality of transaction terminals belonging to any of a plurality of groups, connected to a transaction terminal that transmits a transaction request, and configured from a plurality of processing devices to perform a securities transaction process corresponding to the transaction request ,
The plurality of processing devices are a processing request for executing at least a part of the securities transaction processing, and issues a processing request that may become invalid after issuing the processing request and the processing request (section) Including a second processing device that executes processing according to No. 8),
The first processing apparatus is
Issue the processing request,
Storing requirement information for executing processing to be executed in the processing request corresponding to the processing request in a requirements database;
The second processing device comprises:
Check for issued processing requests,
(1) When there is the processing request, the corresponding requirement information is searched from the requirement database, the corresponding processing is executed,
(2) If there is no processing request, the requirement database is searched for unprocessed requirement information among the processing to be executed by itself.
If there is unprocessed requirement information, issue request information corresponding to the existence of unprocessed requirement information to itself,
A transaction system that receives the request information, acquires corresponding requirement information from the requirement database, and executes a corresponding process. The transaction system according to claim 1,
When there is an unprocessed processing request, the second processing device counts the number of the unprocessed requirement information,
When the corresponding process is executed or when the corresponding requirement information is acquired, the counted number is subtracted by 1,
It is possible to repeat the issue of request information to itself until the subtracted number of cases indicates 0. In the transaction system according to claim 1 or 2,
At least one of the processing request and the request information is information whose own effect disappears after a predetermined time. In the transaction system according to claim 3,
The second processing device stores the processing request and the request information in a storage device,
A transaction system that detects that at least one of the processing request and the request information has expired, and determines that there is no processing request when the detection is detected. In the transaction system according to claim 3 or 4,
The transaction system, wherein the processing request and the request information are a transfer queue. The transaction system according to any one of claims 2 to 5,
The transaction system, wherein the second processing device has the request information for itself equal to or less than the number of unprocessed requirement information counted.

Images