JP6530337B2 - Transaction control system and transaction control method - Google Patents

Description

  The present invention relates to a transaction control system and a transaction control method, and more particularly, to a technology that enables efficient and appropriate failure recovery processing in response to a situation in which the status of a database and a message queue is inconsistent. About.

A gateway is in charge of processing such as channel connection control and telegram conversion / relay between a securities settlement system and a securities company / exchange system connected thereto. This gateway appropriately manages messages sent and received between the above-mentioned settlement system system and business system using a message queue. Also, information necessary for control is held in a database.

  The prior art related to such message queuing is, for example, a business system that executes a predetermined business, and a plurality of servers execute a queue that temporarily stores a message, which is request information requesting the execution of the business. In a business system of shared cluster configuration, means for holding a program for inputting the message, a program for managing the message, a program for executing the business according to the message, and a specific server among the plurality of servers Having means for detecting that a failure has occurred, and means for taking over, among the plurality of servers, a specific server having no failure that manages the message managed by the specific server where the failure has occurred. A business system (see Patent Document 1) and the like having a cluster configuration as a feature is proposed. That.

  A queue control method in the event of a failure in a clustered message queuing system including a plurality of nodes acquiring messages from a plurality of queues having the same name, the node having a queue having the same name as the queue of the faulty node. An other node queue information acquisition control step of taking over the message processing of the failed node as a takeover node and putting the message of the queue possessed by the failed node with the message of the queue possessed by the takeover node under control of the takeover node; A message acquisition control step of passing a message acquired from among messages under the management of the takeover node to the user application when there is a message acquisition request from the user application of the takeover node Sometimes Such as queue control method (refer to Patent Document 2) has been proposed.

Unexamined-Japanese-Patent No. 2007-133795 Unexamined-Japanese-Patent No. 2004-86543

  In the above-described gateway, transaction management targets are a message queue and a database. In the case of a system failure in such a configuration, it is necessary to carry out a recovery process that maintains consistency between the two transactions of the database and the message queue.

However, for certain transactions, for example, problems occur when a situation occurs where commit is successful in the database and commit fails in the message queue.

  In this case, regarding the transaction, the database holds the status of successful message relay. On the other hand, in the message queue, with respect to the transaction, it rolls back in response to a commit failure and returns to the status before message relay.

  As a result, the statuses of the database and the message queue become inconsistent. Also, at this time, since the database is committed, it can not be rolled back automatically using the features of the database.

  Therefore, an object of the present invention is to provide a technology that enables efficient and accurate failure recovery processing in response to a situation in which the status of the database and the message queue is inconsistent.

A transaction control system according to the present invention, which solves the above problems, assigns a unique serial number in the business to a communication device communicating with another device via a network and each message exchanged between the predetermined devices regarding the predetermined business, When mediation processing of the message by message queuing, along with execution of predetermined processing for the message to be sent in the transaction of the task, the serial number managed in the predetermined table regarding the task is incremented, and information on the message is recovered queue Processing for storing the information in the transaction of the task at the start of the transaction of the task in the storage device as recovery information, and the serial number held in the table when a failure occurs in this transaction control system And the serial number held in the recovery queue Combined, the result of collation of the serial number, if the serial number held in the table was found to be greater than serial number held in the recovery queue, based on the recovery information held in the storage device, to roll back the table And a processing unit that executes the processing.

Further, according to the transaction control method of the present invention, an information processing system including a communication device that communicates with another device via a network can use a unique serial number in the task for each message sent and received between the predetermined devices in relation to the task. When the message is given and the message is mediated by message queuing, with the execution of the predetermined process for the message to be sent in the transaction of the task, the serial number managed in the predetermined table for the task is incremented, and the information on the message Processing in the recovery queue, processing for storing the information held regarding the message of the task at the start of the transaction of the task in the storage device as recovery information, and in the event of failure in this transaction control system, Hold the serial number and hold in the recovery queue Collates the turn, result of the matching of the serial number, if the serial number held in the table was found to be greater than serial number held in the recovery queue, based on the recovery information held in said storage device, said table And rolling back processing .

  According to the present invention, it is possible to cope with a situation in which the statuses of the database and the message queue become inconsistent, and perform efficient and accurate failure recovery processing.

It is a network block diagram containing the transaction control system of this embodiment. It is a figure showing an example of hardware constitutions of a transaction control system in this embodiment. It is a figure which shows the data structural example of the process serial number management table of this embodiment. It is a figure which shows the data structural example of the serial number management table of this embodiment. It is a figure which shows the data structural example of the transmission status management table of this embodiment. It is a figure which shows the example 1 of a flow of the transaction control method of this embodiment. It is a figure which shows the example 2 of a flow of the transaction control method of this embodiment.

--- Network configuration ---
Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. FIG. 1 is a network configuration diagram including a transaction control system 100 of the present embodiment. The transaction control system 100 shown in FIG. 1 is a computer system that enables efficient and accurate failure recovery processing in response to a situation in which the status of the database and the message queue is inconsistent.

  The transaction control system 100 according to the present embodiment is a gateway that appropriately converts and mediates a message related to business between the business system 200 and the securities settlement system 300 via the network 10. Among them, the business system 200 is a system used by a securities company or an institutional investor when making an order to buy and sell stocks. In addition, the securities settlement system 300 is a system that performs settlement processing of stock trading orders of the above-mentioned securities company and institutional investors.

  Of course, the network configuration to which the transaction control system 100 is applied is not limited to the example of this embodiment. In a network including a gateway that mediates telegrams by message queuing, any configuration can be applied as long as it is configured to perform transaction management of a message queue and a database.

  As described above, the transaction control system 100, which is the gateway, and the business system 200 and the securities settlement system 300 exchange messages by the message queuing mechanism.

  In this message queuing, when messages are exchanged between devices and linked operation is performed, a message to be sent is temporarily stored in a message queue, and the next processing is performed without waiting for completion of processing on the other side. It is. That is, in a system in which this message queuing system is introduced, the transmitting device can reliably send a message simply by storing the message in the queue area regardless of the convenience of the other device. Even if the communication environment between devices temporarily breaks down, the message will be delivered reliably.

  Therefore, each of the business system 200, the transaction control system 100, and the securities settlement system 300 has a reception message queue and a transmission message queue in its own storage device.

  Among these, the business process system 200 has a message path 250 for sending for billing route and a message queue 251 for receiving for notification path. The transaction control system 100 also has a reception message queue 150 and a transmission message queue 155. Similarly, what the securities settlement system 300 has is a receipt route directed message queue 350 and a notification route directed message queue 351.

  Furthermore, in the transaction control system 100, the reception message queue 150 and the transmission message queue 155 are respectively a reception message queue 151 and a transmission message queue 156 for the billing path, and a reception message queue 152 and a transmission message for the notification path. Queue 157, is present.

  The billing route is a processing route of a message accompanying a settlement request addressed to the securities settlement organization system 300 from the business system 200, and the transaction control system 100 acquires and converts the message sent from the business system 200, It is a series of paths at the time of PUT to a message queue for transmission to the securities settlement system 300.

Further, the notification route is a processing route of the message accompanying the notification of the settlement result addressed to the business system 200 from the securities settlement system 300, and the message control system 100 acquires the message obtained from the securities settlement system 300 This is a series of paths when converting and PUT to a message queue for transmission toward the business system 200.

  The transaction control system 100 according to the present embodiment also holds recovery queues 160 and 161 for each billing route, in addition to the above-described queues. The recovery queues 160 and 161 are queues for storing information on messages in the transaction of the business, for which the serial number is incremented in the serial number management table 126.

  In addition, although not shown in the figure, transmission queues are attached to each transmission message queue, and a message to be transmitted to the securities clearing house system 300 or the business system 200 shall be PUT through this transmission queue. .

--- Hardware configuration ---
The hardware configuration of the transaction control system 100 is as shown in FIG. The transaction control system 100 according to the present embodiment includes a storage device 101 configured of an appropriate non-volatile storage element such as a solid state drive (SSD) or a hard disk drive, a memory 103 configured of a volatile storage element such as a RAM, and the storage device 101. The program 102 held in the unit is read out to the memory 103 and executed to perform overall control of the device itself, as well as to the computing device 104 such as a CPU that performs various determinations, calculations and control processing, and the network 10 to communicate with other devices A communication device 105 responsible for processing is provided.

  In addition to the program 102 for implementing the functions necessary for the transaction control system 100 according to the present embodiment, the storage device 101 or the memory 103 also includes a process serial number management table 125, a serial number management table 126, and a transmission status management table 127. Holds a database 110 in which is stored. The specific configuration of these tables will be described later.

  Further, in a predetermined storage area in the storage device 101 to the memory 103, a message queue for temporarily storing telegraphic messages exchanged between the business system 200 and the securities settlement system 300 is secured.

--- Data structure example ---
Subsequently, a table used by the transaction control system 100 of the present embodiment will be described. FIG. 3 shows an example of the process serial number management table 125 in the present embodiment.

  The processing sequence number management table 125 of the present embodiment is a table for managing the history of acquisition and processing of telegrams regarding transactions of each task by the transaction control system 100 serving as the gateway. In the process serial number management table 125, all messages are targets of history management regardless of whether or not predetermined processing such as format conversion in the transaction control system 100 has succeeded.

  The data structure is a collection of records including data such as a route type and a process sequence number, using as a key a business ID that uniquely identifies (the transaction of) the corresponding business that has received a settlement request from the business system 200.

  Among these, the route type is a route (that is, a transmission route) in which the transaction of the business task transmits a message to the business system 200 or the securities settlement system 300 or receives the message from the business system 200 or the securities settlement system 300 It is a value indicating which of the paths (ie, reception paths) corresponds to (see also FIG. 1).

  The processing sequence number is a sequence number which is incremented by the transaction control system 100 when the message is obtained (GET) from the message queue for the transaction of the business. Therefore, the value increases by one each time the transaction control system 100 acquires the message of the relevant task from the message queue.

  Further, FIG. 4 shows an example of the serial number management table 126 of the present embodiment. The serial number management table 126 of the present embodiment is a table for managing a history when a predetermined process such as format conversion succeeds when the transaction control system 100 acquires and processes a message regarding a transaction of each task.

  The data structure is a collection of records including data such as a route type, a transmission date, a management path number of a billing path, and a management path number of a notification path, using a task ID common to the processing serial number management table 125 described above as a key.

  Among these, the transmission date is the date when the message is stored (PUT) most recently in the transmission message queue in the transaction of the business.

  In addition, the management sequence number of the billing route is for transmission / transmission toward the securities clearinghouse system 300 by acquiring and converting the message accompanying the settlement request addressed to the securities clearinghouse system 300 from the business system 200 by the transaction control system 100. It is a serial number in a series of transactions put into the message queue.

  Further, the management sequence number of the notification route is for transmission / transmission toward the business system 200 by acquiring and converting the message accompanying the notification of the settlement result addressed to the business system 200 from the securities settlement organization system 300 by the transaction control system 100. It is a serial number in a series of transactions put into the message queue.

  Further, FIG. 5 shows an example of the transmission status management table 127 of this embodiment. The transmission status management table 127 of this embodiment relates to the point in time when the corresponding telegram is GET from the message queue for reception (due to work in progress) with respect to the transaction whose history of processing is managed in the above-mentioned serial number management table 126 It is a table that manages the commit status of the message in the message queue at the time of processing and PUT in the message queue for transmission (sent).

  The data structure is a collection of records including data such as path type, transmission status, and recovery information, using a task ID common to the process serial number management table 125 and the serial number management table 126 described above as a key.

  Among them, the transmission status is one of “in progress” corresponding to the above-mentioned GET event and “sent” according to the PUT event. Further, the recovery information stores information held in the serial number management table 126 regarding the transaction of the business prior to the above-mentioned PUT processing.

--- Flow example 1--
Hereinafter, the actual procedure of the transaction control method in the present embodiment will be described based on the drawings. Various operations corresponding to the transaction control method described below are realized by a program which the transaction control system 100 reads out to a memory or the like and executes. The program is composed of code for performing various operations described below.

  FIG. 6 is a diagram showing a flow example 1 of the transaction control method in the present embodiment. Here, a normal process flow executed by the transaction control system 100 as a gateway will be described. On the other hand, a process according to the occurrence of a failure is shown in flow example 2.

  For example, it is assumed that the telegram of the settlement request from the business system 200 is stored in the reception message queue 151 of the billing route via the channel which is the billing route. The transmission and reception of messages via the channel itself appropriately employs the existing message queuing technology. In this case, the transaction control system 100 starts a transaction related to the settlement request work of the business system 200 in response to the message storage event in the reception message queue (s100). The transaction started here is a transaction regarding update management of the reception message queue 150, the transmission message queue 155, and the database 110.

  Next, the transaction control system 100 GETs a telegram from the above-mentioned reception message queue 151 (s101).

  In addition, the transaction control system 100 extracts information currently held by each of the processing serial number management table 125, the serial number management table 126, and the transmission status management table 127 regarding the transaction of the business, and transmits the information as the transmission status. It stores in the recovery information column of the said record of the management table 127 (s102).

  Subsequently, the transaction control system 100 increments the processing sequence number of the record of the processing sequence number management table 125 regarding the transaction of the task (s103).

  Further, the transaction control system 100 executes a process of converting the message into a message format for the securities settlement system 300, and increments the processing sequence number of the record of the serial number management table 126 for the transaction of the business. (S104). Here, the flow will be described on the assumption that the conversion process described above succeeds.

  Next, the transaction control system 100 updates the transmission status column of the transmission status management table 127 to "pending" for the transaction of the business concerned (s105).

  In addition, the transaction control system 100 relates to the target message in which the processing sequence number of the serial number management table 126 has been incremented at s104 described above, information such as the task and the route type together with the processing sequence number (in this case, for the billing route) 160 (106).

  In addition, the transaction control system 100 PUTs the message to the transmission route-for-request message queue 156 (s107).

The transaction control system 100 commits the transaction related to the database 110 in accordance with the execution of the PUT described above (s108). Similarly, the transaction control system 100 commits the transaction related to the message queue 150, 155 (s109). A transaction is all operations on the database 110 and the message queues 150 and 155 completed ("commit") or canceled ("commit") between "start" processing of the transaction and "commit / rollback" processing. It is guaranteed to be "rolled back". Therefore, with the commit, when the transaction is committed, the updated contents added to the database 110 and the message queues 150 and 155 become permanent.

  The transaction control system 100 which has executed the above-mentioned commit starts the update operation of the transmission status management table 127 as a new transaction regarding the operation (s110).

  In this case, the transaction control system 100 updates the transmission status column of the transmission status management table 127 regarding the relevant business to "sent" (s111).

  Further, the transaction control system 100 commits the transaction (s112) with the update of the transmission status field described above (s112), and ends the process.

--- Flow example 2--
Next, the handling process when a failure occurs in the transaction control system 100 will be described based on the drawings. FIG. 7 is a diagram showing a second flow example of the transaction control method in the present embodiment.

  In this case, it is assumed that the transaction control system 100 receives a notification of occurrence of a failure from itself or from the failure monitoring function provided in another device (s200).

  The transaction control system 100 executes rollback processing on the message queues 150 and 155 when the notification is received between s100 and s108 in the above-described flow example 1 (s201: y) s202). Similarly, the transaction control system 100 executes rollback processing on the database 110 (s203). Similar to conventional rollback, such rollback is restoration processing based on information (for example, recovery information in the transmission status management table 127) related to the state before the start of the transaction.

  On the other hand, if the time when the above notification is received is between s108 and s112 (s201: n) in the above flow example 1 (s201: n), the transaction control system 100 causes the serial number management table 126 to The process sequence number held is compared with the process sequence number indicated by the information held in the recovery queue 160 (s204).

  If it is determined that the process sequence number held in the sequence number management table 126 is larger than the process sequence number held in the recovery queue 160 (s 205: large), the transaction control system 100 determines in the transmission status management table 127 Each table 125 to 127 included in the database 110 is rolled back (s206) based on the recovery information held for the transaction of the task (s206), and the flow is ended.

  This process involves any failure in the transaction control system 100 (gateway) from the timing (s108) of committing the transaction in the database 110 to the commit (s109) in the message queues 150 and 155. Correspond to the situation where the

In such a situation, rollback occurs in the message queues 150 and 155 in response to the occurrence of a failure, and the processing sequence number is returned until the start of the transaction, while no rollback occurs in the database 110, and the processing sequence number is It is a situation that remains the latest status. That is, the statuses of the database 110 and the message queues 150 and 155 are inconsistent. In such a situation, the transaction control system 100 performs a rollback on the database 110 and matches its status with the status in the message queue 150, 155.

  On the other hand, if the process serial number held in the serial number management table 126 matches the process serial number held in the recovery queue 160 as a result of the collation described above (s 205: coincident), the transaction control system 100 determines in the transmission status management table 127 The transmission status held for transaction of business is updated to "sent" (s207), and the flow is ended.

  In this case, in response to the situation where a failure occurs after the transaction commits in each of the database 110 and the message queues 150 and 155 described above, only the response to update the transmission status regarding the transaction is executed, and processing such as rollback is performed. It can be avoided.

  On the other hand, if it is determined that the process sequence number held in the sequence number management table 126 is smaller than the process sequence number held in the recovery queue 160 (s205: small), the transaction control system 100 sends a predetermined error notification. , And a terminal for a system administrator (s208) to end the flow.

  This situation is a situation that can not occur in a normal failure, so that the system administrator etc. can be notified promptly and surely to that effect, and in turn, efficient and appropriate failure recovery processing can be made.

  As mentioned above, although the best mode etc. for carrying out the present invention were concretely explained, the present invention is not limited to this, and can be variously changed in the range which does not deviate from the gist.

  According to the present embodiment, it is possible to cope with the situation where the statuses of the database and the message queue become inconsistent, and perform efficient and appropriate failure recovery processing.

  At least the following matters will be made clear by the description of the present specification. That is, in the transaction control system of the present embodiment, the arithmetic unit further executes a process of storing the information held regarding the message of the task at the start of the transaction of the task in the storage device as recovery information, and If it is determined that the serial number held in the table is larger than the serial number held in the recovery queue as a result of the collation, the table may be rolled back based on recovery information held in the storage device. .

  In this case, it is possible to cope with a situation where some failure has occurred in the system (gateway) between the timing of committing the transaction in the above table and the commit of the transaction in the message queue. In such a situation, rollback occurs in the message queue in response to the occurrence of a failure, and status such as serial number is returned until the start of the transaction, while rollback does not occur in the table and serial number etc is the latest status. It is a situation that is as it is. In other words, there is a situation where the status of the table (the database in which it is stored) and the status of the message queue are inconsistent. The transaction control system can perform rollback on the table in such situations and make its status consistent with the status in the message queue. Therefore, efficient and accurate failure recovery processing is possible.

Further, in the transaction control system according to the present embodiment, when the serial number held in the table matches the serial number held in the recovery queue as a result of the collation of the serial numbers, the arithmetic unit holds the transaction in the table with respect to the transaction. Status may be updated to have been sent a message.

  In this case, in response to a situation where a failure occurs after the transaction commits in each of the above-mentioned table and message queue, only the response to update the transmission status regarding the transaction can be executed, and processing such as rollback can be avoided. . As a result, efficient and accurate failure recovery processing is possible.

  Further, in the transaction control system according to the present embodiment, when the arithmetic device determines that the serial number held in the table is smaller than the serial number held in the recovery queue as a result of the collation of the serial numbers, a predetermined error notification is issued. It may be output to a predetermined device.

  This situation is a situation that can not occur in a normal failure, so that the system administrator etc. can be notified promptly and surely to that effect, and in turn, efficient and appropriate failure recovery processing can be made.

  In the transaction control method of the present embodiment, the information processing system further executes a process of storing the information held regarding the message of the task at the start of the transaction of the task in the storage device as recovery information, and collating the serial number As a result, when it is determined that the serial number held by the table is larger than the serial number held by the recovery queue, the table may be rolled back based on the recovery information held by the storage device.

  In the transaction control method of the present embodiment, when the serial number held by the information processing system matches the serial number held by the table as a result of the collation of the serial numbers, the information processing system holds the transaction in the table. The status may be updated to sent message.

  In the transaction control method of the present embodiment, when the information processing system determines that the serial number held in the table is smaller than the serial number held in the recovery queue as a result of the collation of the serial numbers, a predetermined error notification is given. It may be output to the device.

10 Network 100 Transaction control system 101 Storage device 102 Program 103 Memory 104 Arithmetic unit 105 Communication unit 110 Database 125 Processing sequence number management table 126 Sequence number management table 127 Transmission status management table 150 Reception message queue 151 (For billing route) Reception message queue 152 (For notification route) Reception message queue 155 Transmission message queue 156 (For billing route) Transmission message queue 157 (For notification route) Transmission message queue 160 (For billing route) Recovery queue 161 (For notification route) Recovery Queue 200 Business system 250 (For billing route) Message queue for transmission 251 (For notification route) Message queue for reception 300 Securities settlement system Beam 350 (according path for) the message queue 351 (for notification path) for receiving the transmission message queue

Claims (6)

A communication device that communicates with other devices via a network;
A unique serial number is assigned to each message sent and received among the predetermined devices regarding the predetermined job, and when the message is brokered by message queuing, the predetermined process for the message to be sent in the transaction of the job With execution, the serial number managed by the predetermined table regarding the business is incremented, processing of storing the information about the electronic message in the recovery queue, and the information held regarding the electronic message of the business at the start of the transaction of the business as recovery information The processing stored in the storage device and the serial number held in the table are collated with the serial number held in the recovery queue when a failure occurs in the transaction control system, and the serial number held in the table as a result of the collation of the serial number Is greater than the serial number held in the recovery queue If you bright, on the basis of the recovery information held in the storage device, an arithmetic unit for executing a process of rolling back the table,
A transaction control system comprising: The arithmetic device is
If, as a result of the collation of the serial numbers, the serial numbers held in the table and the serial numbers held in the recovery queue match, the status held for the transaction in the table is updated to the transmitted message.
The transaction control system according to claim 1, characterized in that: The arithmetic device is
As a result of the collation of the serial numbers, when it is found that the serial numbers held in the table are smaller than the serial numbers held in the recovery queue, a predetermined error notification is outputted to a predetermined device. Transaction control system according to 1. An information processing system provided with a communication device that communicates with another device via a network,
A unique serial number is assigned to each message sent and received among the predetermined devices regarding the predetermined job, and when the message is brokered by message queuing, the predetermined process for the message to be sent in the transaction of the job A process of incrementing a serial number managed by a predetermined table in relation to the task and storing information on the message in a recovery queue according to the execution;
A process of storing, as recovery information, information held about a message of the task at the start of the transaction of the task in a storage device;
When a failure occurs in this transaction control system, the serial number held in the table and the serial number held in the recovery queue are collated, and as a result of the collation of the serial number, the serial number held in the table is held in the recovery queue If it is found to be larger , processing for rolling back the table based on recovery information held by the storage device ;
A transaction control method characterized in that: The information processing system
If, as a result of the collation of the serial numbers, the serial numbers held in the table and the serial numbers held in the recovery queue match, the status held for the transaction in the table is updated to the transmitted message.
5. A transaction control method according to claim 4 , wherein: The information processing system
When it is determined that the serial number held in the table is smaller than the serial number held in the recovery queue as a result of the collation of the serial numbers, a predetermined error notification is output to a predetermined device.
5. A transaction control method according to claim 4 , wherein:

Images