JP2009175854A - Program, method and computer system for securing data consistency - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To execute a plurality of DB update processes while securing consistency when unified control of transaction cannot be performed because processes or servers executing the DB update process are distributed. <P>SOLUTION: In this method, a unique ID is issued according to a business processing request from a business processing client, an update instruction based on a DB update request is outputted to a DB according to the DB update request from any business processing program for processing the business processing request, the update instruction is registered in an issuance instruction log table correspondingly to the ID, a cancellation instruction of the update instruction is outputted to the DB regardless of success/failure of an update process by the update instruction, which is repeated, the update instruction registered in the issuance instruction log table is outputted to the DB correspondingly to the ID issued to the business processing request when the processing to the business processing request is normally completed, and a commit instruction for deciding update by the update instruction is outputted to the DB. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a technique for ensuring data consistency in a plurality of database update processes executed in response to one business process request by a plurality of related business process programs.

  As a technique for ensuring data consistency in distributed processing, there is a technique called two-phase commit (two-phase commit), and it is said that processing can be performed safely even in a distributed transaction environment. However, in reality, it is difficult to say that application to real systems is progressing, such as a three-phase commit being devised for performance concerns and troubleshooting.

  When distributed transaction processing is performed without using two-phase commit, database transactions are generally committed / rolled back on a computer-by-computer basis. If an error occurs in the middle, cancellation of committed processing is performed. It is necessary to perform processing.

  Creating this cancellation process individually is not only a burden in application program development, but also when the update is further performed by other processes, etc., and it becomes impossible to cancel, or even the cancellation process becomes an error However, there is a risk of falling into a state where autonomous recovery can no longer be expected.

  Japanese Patent Laid-Open No. 2000-20369 discloses a system that restores a database to a state immediately before a failure occurs. Specifically, the client machine converts the transaction that occurred on the current day into an SQL statement, adds the occurrence time data and sequentially stores it in a transaction data file, and the server machine backs up the last database of the previous day to the previous day's data storage unit. Then, the transaction executed independently on that day on the machine is converted into an SQL statement, and the generation time data is added and sequentially stored in the transaction data file. When a failure occurs, the transaction data executed on the server machine on the current day and the transaction data executed on each client machine are collected and sorted in the order of occurrence, and all transactions for the current day are based on the last database of the previous day. Are executed again in the order of occurrence to restore the database to the state just before the failure occurred. However, it does not target distributed transaction processing as described above.

Furthermore, Japanese Patent Application Laid-Open No. 2006-268389 discloses a technique for protecting an appropriate long transaction process by performing a proper confirmation process by removing an inappropriate access with a simple configuration. Has been. Specifically, a provisional execution database for storing provisionally executed items, a confirmation database for storing confirmed items, and a latest data reference function for retrieving the requested items in the provisional execution database by a search request An update provisional execution function unit that updates the requested item in the provisional execution database by a provisional execution request, and a corresponding item of the provisional execution database is added to the requested item in the confirmation database by a confirmation request. An update confirmation function unit for copying data and an update cancellation function unit for copying the data of the corresponding item of the confirmation database to the requested item in the temporary execution database in response to a cancellation request. However, it does not target distributed transaction processing as described above.
JP 2000-20369 A JP 2006-268389 A

  As described above, multiple DB update processes can be performed while ensuring consistency in situations where unified transaction control is not possible because servers and processes that execute DB update processes are distributed. However, there is no practical technique for determining database update only when a plurality of DB update processes succeeds normally.

  Accordingly, an object of the present invention is to enable a plurality of DB update processes to be performed while ensuring consistency in a situation where unified transaction control cannot be performed because servers and processes that execute DB update processes are distributed. Is to provide technology for

  Another object of the present invention is only when a plurality of DB update processes succeeds normally in a situation where unified transaction control cannot be performed because servers and processes for executing the DB update processes are distributed. It is to provide a new technique for confirming database update.

  Furthermore, another object of the present invention is carried out when the processing does not end normally even in a system in which unified transaction control cannot be performed because servers and processes for executing DB update processing are distributed. It is to provide a method for avoiding the need to develop a revocation process individually.

  The present method for ensuring data consistency in a plurality of database update processes executed in response to a single business process request by a plurality of related business process programs includes: (a) a business process request from a business process client; In response, a step of issuing a unique transaction ID, and (b) a first database update request based on the first database update request in response to a first database update request from any one of the business process programs that process the business process request. 1 update command is output to the database, the first update command is registered in the issuance command log table corresponding to the transaction ID, and the first update command is canceled regardless of whether the update process is successful or not. A processing step for outputting a command to a database, and (c) when processing for a business processing request is normally completed A commit instruction for outputting the first update instruction registered in the issued instruction log table corresponding to the transaction ID issued in response to the business process request to the database, and further confirming the update by the first update instruction. And a confirmation step for outputting to the database.

  Even when servers and processes that execute DB update processing are distributed, even if the processing ends abnormally in the middle by performing the processing described above, it is possible to perform cancellation processing separately. As a whole, data consistency can be ensured. Note that the output order of a plurality of update instructions based on requests from a plurality of business processing programs needs to be held, and for this purpose, the order may be managed in the issued instruction log table.

  If the process for the business process request is not completed normally, the update instruction registered in the issued instruction log table corresponding to the transaction ID issued for the business process request is discarded or the update instruction An error processing step for performing at least one of registration in the issuance instruction log table of data for invalidating the data may be further included. In this way, it is not necessary to separately perform a cancellation process, so that the system can be easily developed.

  Further, in the processing steps described above, before outputting the update command to the database, it may be determined whether the update command for the same table and the same record is effectively held by referring to the issued command log table. Also, in the error processing step described above, when it is determined by the processing step that the database update request for the same table and the same record is effectively held in the issued command log table, the processing for the business processing request is performed normally. Issuance of the update instruction registered in the issuance instruction log table corresponding to the transaction ID issued in response to the business process request as not completed, or issuance instruction log of data that invalidates the update instruction You may perform at least any one of the registration to a table. This makes it possible to properly handle exclusive errors.

  A program for causing a computer to execute the method according to the present invention can be created, and the program is stored in a storage medium or storage device such as a flexible disk, a CD-ROM, a magneto-optical disk, a semiconductor memory, or a hard disk. Is done. In some cases, digital signals are distributed over a network. Note that data being processed is temporarily stored in a storage device such as a computer memory.

  According to the present invention, it is possible to perform a plurality of DB update processes while ensuring consistency in a situation where unified transaction control cannot be performed because servers and processes that execute DB update processes are distributed. .

  According to another aspect of the present invention, when a plurality of DB update processes succeeds normally in a situation where unified transaction control cannot be performed because servers and processes that execute DB update processes are distributed. Only the database update can be confirmed.

  According to still another aspect of the present invention, even in a system in which unified transaction control cannot be performed because servers and processes that execute DB update processing are distributed, the processing is performed when the processing does not end normally. There is no need to develop a separate cancellation process.

  An outline of a system according to an embodiment of the present invention is shown in FIG. For example, a network 1 such as the Internet or a LAN (Local Area Network) includes one or a plurality of client terminals 3 that execute a business processing client program and transmit a business processing request to an AP (Application) server via the network 1. A plurality of AP servers 5 (AP server A, AP server B, and AP server C in FIG. 1) that execute user applications (in FIG. 1, user applications a, b, and c) that are business processing server programs. It is connected. Each AP server 5 is connected to each other via a network 7 such as a LAN, and further connected to a DB server 9 via the network 7.

  The user application executed in each AP server 5 executes necessary processing in response to a business processing request from the client terminal 3 and executes processing in cooperation with each other. For example, the user application a may call the user applications b and c to request processing. Further, when each user application needs to refer to and update the database managed by the DB server 9, the DB access components associated therewith (in the example of FIG. 1, the DB access component a and the DB access component b are used). , DB access component c) is used.

  In the present embodiment, the DB server 9 manages the user DBA and the user DBB, and also manages an issuance SQL (Structured Query Language) log table 93 for the present embodiment.

  FIG. 2 shows a functional block diagram of the DB access component. The DB access components include a user DBA access component 511, a user DBB access component 513, an update SQL batch execution component 515, and a business transaction control component 517. The user DBA access component 511 is an access component for the user DBA, and includes an update SQL issue unit 5111 and an issue SQL save unit 5113. The user DBB access component 513 is an access component for the user DBB, and includes an update SQL issue unit 5131 and an issue SQL save unit 5133. The update SQL batch execution component 515 includes a DB batch update unit 5151. Further, the business transaction control component 517 includes a ROLLBACK (rollback) unit 5171 and a COMMIT (commit) unit 5173.

  FIG. 3 shows the data structure of the issue SQL log table 93. The issue SQL log table 93 includes, for each issue SQL, a transaction ID given to the entire series of processes from reception of a business process request to response reply and a plurality of issue SQLs issued in response to one business process request. An issue SQL sequence number for managing the issue order, an issue SQL that is a SQL issued by a DB access component in response to a request from a user application, an update target table that is a table to which the issue SQL is an update target, The transaction is completed, the update target identification key that is a character string that specifies the extraction condition for specifying the update target in the issued SQL, the SQL execution result that is the code returned from the DBMS (DB Management System) after issuing the issued SQL The transaction state which is a flag indicating whether or not the transaction has been performed is held.

  Next, the outline of the processing according to the present embodiment will be described with reference to FIGS. Here, it is assumed that the AP server A receives a business process request from the client terminal 3. As shown in FIG. 4, when the user application a receives the business process request, the user application a numbers the transaction ID and executes its own business process. If necessary, the user application b calling unit of the user application a 611 calls the user application b running on the AP server B and requests processing. At this time, the transaction ID is notified to the AP server B.

  Next, as shown in FIG. 5, when the user application b of the AP server B is called, it executes a predetermined business process and, if necessary, requests a DB update to the user DBA from the DB access component b. Is output. When the DB access component b receives a DB update request for the user DBA, the update SQL issuing unit 5111 of the user DBA access component 511 issues an update SQL statement corresponding to the DB update request and transmits it to the DB server 9. . When the DB server 9 receives the update SQL statement from the AP server B, the DB server 9 performs update processing as instructed to the user DBA, and sends the processing result to the update SQL issuing unit 5111 of the requesting user DBA access component 511. Send back. In the user DBA, an updated record 911 corresponding to the updated SQL statement is held.

  Thereafter, as shown in FIG. 6, the issue SQL saving unit 5113 of the user DBA access component 511 requests the DB server 9 to register the SQL statement issued in FIG. 5 in the issue SQL log table 93. When the DB server 9 receives from the AP server B a request for registering the issued SQL statement for the issued SQL log table 93, the DB server 9 registers the issued SQL statement in the issued SQL log table 93. The issue SQL statement is registered in the issue SQL log table 93 as an issue SQL statement 931. As described above, the data is registered in the issue SQL log table 93 with the data structure shown in FIG. At this stage, “1” signifying the first is registered as the issued SQL sequence number, and “1” representing in-process is set as the transaction state.

  Furthermore, as shown in FIG. 7, the user application b of the AP server B outputs a DB update request for the user DBB to the DB access component b when necessary. When the DB access component b receives a DB update request for the user DBB, the update SQL issuing unit 5131 of the user DBB access component 513 issues an update SQL statement corresponding to the DB update request and transmits it to the DB server 9. . When the DB server 9 receives the update SQL statement from the AP server B, the DB server 9 performs update processing as instructed to the user DBB, and sends the processing result to the update SQL issuing unit 5131 of the requesting user DBB access component 513. Send back. In the user DBB, a post-update record 912 corresponding to the update SQL sentence is held.

  Thereafter, as illustrated in FIG. 8, the issue SQL saving unit 5133 of the user DBB access component 513 requests the DB server 9 to register the SQL statement issued in FIG. 7 in the issue SQL log table 93. When the DB server 9 receives from the AP server B a request for registering the issued SQL statement for the issued SQL log table 93, the DB server 9 registers the issued SQL statement in the issued SQL log table 93. The issue SQL statement is registered in the issue SQL log table 93 as an issue SQL statement 932. As described above, the data is registered in the issue SQL log table 93 with the data structure shown in FIG. At this stage, “2”, which means the second, is registered as the issued SQL sequence number, and “1” indicating in-process is set as the transaction state.

  Then, as shown in FIG. 9, when the processing of the user application b is completed, the ROLLBACK unit 625 of the user application b performs the business transaction control component 517 of the DB access component b regardless of whether the processing ends normally or abnormally. Request a rollback (ROLLBACK). The ROLLBACK unit 5171 of the business transaction control component 517 transmits an SQL statement for ROLLBACK to the DB server 9 in response to a request from the user application b. Thereby, the DB server 9 returns the updated record 911 in the user DBA to the pre-update record 911 ', and returns the updated record 912 in the user DBB to the pre-update record 912'. Then, the user application b returns a return value indicating the end of processing to the user application a of the AP server A. When an error occurs in the process in the user application b, a return value indicating the error is returned to the user application a.

  Thereafter, as shown in FIG. 10, when the user application a receives the return value from the user application b, the user application a performs necessary business processing, and if necessary, the user application c calling unit 613 of the user application a The user application c running on the AP server C is called to request processing. At this time, the transaction ID is notified to the AP server C.

  In the AP server C, the same processing as that of the AP server B is performed, and when the user DBA or the user DBB needs to be updated, the user application c outputs a request to the DB access component c. The DB access component c transmits an update SQL statement to the DB server 9 to update the user DBA or the user DBB once, and also registers the update SQL statement in the issue SQL log table 93. Then, regardless of the success or failure of the update, the ROLLBACK is executed to return the user DBA or the user DBB to the original state. Then, the user application c returns a return value to the user application a of the AP server A as a processing result.

  When it is determined that the process is completed in the user application a of the AP server A, the batch COMMIT process calling unit 615 of the user application a performs the update SQL batch execution component 617 of the DB access component a as shown in FIG. The DB batch update unit 6171 is requested to perform batch DB update. Then, the DB batch update unit 6171 of the update SQL batch execution component 617 transmits an issued SQL acquisition request including the transaction ID related to the process to the DB server 9. When the DB server 9 receives the issued SQL acquisition request including the transaction ID, the DB server 9 reads the issued SQL statements related to the transaction ID from the issued SQL log table 93 in ascending order of the issued SQL sequence number, and the DB access component a of the AP server A Reply to When the DB batch update unit 6171 of the update SQL batch execution component 617 in the DB access component a of the AP server A receives the update SQL statement for the user DBA and the update SQL statement for the user DBB from the DB server 9, the DB server 9 Send to. When the DB server 9 receives an update SQL statement for the user DBA, the DB server 9 performs an update process corresponding to the update SQL statement for the user DBA, and causes the user DBA to hold the updated record 911. Similarly, when the DB server 9 receives the update SQL statement for the user DBB, the DB server 9 performs an update process according to the update SQL statement for the user DBB, and causes the user DBB to hold the updated record 912.

  When the update to the user DBA and the user DBB by the DB batch update unit 6171 is normally successful, the COMMIT unit 6193 of the business transaction control component 619 in the DB access component a sends the DB server 9 as shown in FIG. Then, the SQL statement for COMMIT of the update SQL statement for the user DBA is output, and further, the SQL statement for COMMIT of the update SQL statement for the user DBB is output to the DB server 9. When the DB server 9 receives the SQL statement for COMMIT, the DB server 9 determines the update for the user DBA and the user DBB. When the above processing is completed, the COMMIT unit 6193 of the business transaction control component 619 indicates to the DB server 9 that the transaction status of the record corresponding to the transaction ID related to the processing indicates that the processing is completed in the issued SQL log table 93. Register to be "0".

  Further, when the above processing is normally completed, the collective COMMIT processing calling unit 615 of the user application a transmits a response notification to the client terminal 3 that is the transmission source of the business processing request. Thereby, the process corresponding to the business process request is completed. If an abnormality occurs at any stage, the abnormal termination is returned as a response at that stage and returned to the client terminal 3 that is the transmission source of the business process request.

  By executing such processing, the update to the user DB is always ROLLBACK, and if it is not confirmed that all the updates to the user DB are normally completed, the update is not performed. However, the update SQL statement is managed with the transaction ID and the issue SQL sequence number in the issue SQL log table 93. If it is confirmed that all updates to the user DB are completed normally, the update SQL statement is registered in the issue SQL log table 93. The necessary update is performed on the user DB using the stored data, and is committed. By performing such a two-stage process, even if the process and server for executing the DB update process are distributed as shown in FIGS. 4 to 12, the unified transaction management cannot be performed. Even if an abnormality occurs midway, the user DB can be returned to the original state without preparing and executing an individual cancellation process for that purpose. In other words, the above-described effects can be obtained by always performing ROLLBACK for confirmation for the user DB and preparing the issue SQL log table 93 for performing batch update later. It becomes like this.

  Next, specific processing contents will be described with reference to FIGS. First, for example, the user application a of the AP server A receives a business process request from the client terminal 3 (step S1). Then, the user application a outputs a transaction ID numbering request to the DB access component a (step S3). The DB access component a receives a transaction ID numbering request from the user application a (step S5) and issues a transaction ID (step S7). At this time, the DB access component “a” may independently issue a transaction ID. For example, the DB access component “a” outputs a request to read the current latest transaction ID to the issue SQL log table 93 of the DB server 9. The current transaction ID may be issued according to the current latest transaction ID. The DB access component a holds the transaction ID issued this time.

  Then, the DB access component a outputs the numbered transaction ID to the user application a (step S9). The user application a receives the transaction ID from the DB access component a and holds it in a storage device such as a main memory (step S11). Then, the user application “a” performs a predetermined business process (step S13). When it is necessary to update the data held in the user DBA or the user DBB managed by the DB server 9 in this predetermined business process, a DB update request including a transaction ID is output to the DB access component a (step S15). The DB update request may be the update SQL statement itself, and includes data necessary for constructing the update SQL statement (update target table name, conditional clause for specifying the update target record, update contents, etc.). In some cases.

  When the DB access component a receives a DB update request including a transaction ID from the user application a (step S17), the user DB access component update SQL issuance for the DB access component a (DB to be updated (also called a table)) is issued. In order to confirm that the exclusive error does not occur, the part) transmits a request to the DB server 9 to confirm the presence / absence of the in-process processing for the same table and the same record (step S19). Specifically, the DB server is configured to search the issued SQL log table 93 using the condition clause for specifying the update target table name and the update target record among the data necessary for configuring the update SQL statement. 9 The DB server 9 searches the update target table and the update target specifying key in the issued SQL log table 93 based on the received update target table name and the conditional clause for specifying the update target record. Based on this search result, it is determined whether or not there is another transaction that is updating the same table and the same record, and if there is, it is determined whether the transaction state is “1” indicating that the transaction is in progress. The determination may be made by the DB server 9 or the DB access component a.

  If there is another transaction that is trying to update the same table and the same record, and the transaction status indicates that the transaction is in progress, no further processing is performed due to an exclusive error, and the DB The access component a notifies the user application a of an exclusion error. The user application “a” notifies the client terminal 3 of the business process request source of the error.

  On the other hand, if there is no other transaction to update the same table and the same record, or the transaction state indicates a completed state even if it exists, the DB access component a (user DB access component) The update SQL issuing unit) further requests the DB server 9 to search the issued SQL log table 93 with the received transaction ID. The DB server 9 receives the request including the transaction ID, searches the issue SQL log table 93, and extracts the issue SQL sequence number of the corresponding record. The DB server 9 transmits, for example, the largest number among the issued SQL sequence numbers to the DB access component a. All the issued SQL sequence numbers extracted may be transmitted to the DB access component a. For example, when the DB access component a receives the largest number among the issued SQL sequence numbers, the DB accessed component a increments the largest issued SQL sequence number by 1 and issues the issued SQL sequence number used this time (step S21).

  Then, the DB access component a (user DB access component update SQL issuing unit) issues an update SQL statement based on the DB update request to the DB server 9 (step S23). When the DB server 9 receives the update SQL statement from the DB access component a, the DB server 9 performs a temporary update of the user DB based on the update SQL statement. An error may occur at this time. When an error occurs, the DB access component a is notified to that effect.

  On the other hand, when the update process using the update SQL statement is normally completed, the DB server 9 notifies the DB access component a to that effect. Then, the DB access component a (user DB access component issuance SQL saving unit) displays the transaction ID, issue SQL sequence number, update SQL statement, update target table name (DB name), update target specific key, SQL execution result (success) (Or failure) and an update SQL statement registration request including a transaction status of “1” indicating that the work is in progress is transmitted to the DB server 9 (step S25). The DB server 9 receives the update SQL registration request as described above, and registers it in the issued SQL log table 93. Then, the DB server 9 returns the processing result to the DB access component a. This update process is immediately committed (COMMIT).

  When the DB access component a receives the processing result indicating the normal end from the DB server 9, the DB access component a notifies the user application a of the normal processing end (step S27). The user application a receives a normal process end notification from the DB access component a (step S29). The processing shifts to the processing in FIG.

  When the user application a has to request the user application b of the AP server B in response to the business process request, the user application a sends a call to the user application b including necessary data and a transaction ID to the AP server B. (Step S31). The user application b of the AP server B receives the user application b call including necessary data and the transaction ID from the AP server A, and stores the transaction ID in a storage device such as a main memory (step S33).

  Then, the user application b performs a predetermined business process (step S35). When it is necessary to update the data held in the user DBA or the user DBB managed by the DB server 9 in this predetermined business process, a DB update request including a transaction ID is output to the DB access component b (step S37).

  When the DB access component b receives a DB update request including a transaction ID from the user application b (step S39), the DB access component b issues an update SQL issuance of the user DB access component for the DB access component b (update target DB (also referred to as a table)). Part) transmits to the DB server 9 a request for confirming whether or not there is an in-process process for the same table and the same record in order to confirm that no exclusion error occurs (step S41). Specifically, the DB server is configured to search the issued SQL log table 93 using the condition clause for specifying the update target table name and the update target record among the data necessary for configuring the update SQL statement. 9 The DB server 9 searches the update target table and the update target specifying key in the issued SQL log table 93 based on the received update target table name and the conditional clause for specifying the update target record. Based on this search result, it is determined whether or not there is another transaction that is updating the same table and the same record, and if there is, it is determined whether the transaction state is “1” indicating that the transaction is in progress. The determination may be made by the DB server 9 or the DB access component b.

  If there is another transaction that is trying to update the same table and the same record, and the transaction status indicates that the transaction is in progress, no further processing is performed due to an exclusive error, and the DB The access component b notifies the user application b of an exclusion error. The user application b notifies the calling user application a of the error.

  On the other hand, if there is no other transaction to update the same table and the same record, or the transaction state indicates a completed state even if it exists, the DB access component b (user DB access component) The update SLQ issuing unit) further requests the DB server 9 to search the issued SQL log table 93 with the received transaction ID. The DB server 9 receives the request including the transaction ID, searches the issue SQL log table 93, and extracts the issue SQL sequence number of the corresponding record. The DB server 9 transmits, for example, the largest number among the issued SQL sequence numbers to the DB access component b. All the issued SQL sequence numbers extracted may be output to the DB access component b. For example, when the DB access component b receives the largest number of the issued SQL sequence numbers, the DB accessed component b increments the largest issued SQL sequence number by 1 and issues the issued SQL sequence number used this time (step S43).

  Then, the DB access component b (user DB access component update SLQ issuing unit) issues an update SQL statement based on the DB update request to the DB server 9 (step S45). When the DB server 9 receives the update SQL statement from the DB access component b, the DB server 9 performs a temporary update of the user DB based on the update SQL statement. An error may occur at this time. When an error occurs, the DB access component b is notified to that effect.

  On the other hand, when the update process using the update SQL statement is normally completed, the DB server 9 notifies the DB access component b to that effect. Then, the DB access component b (user DB access component issuance SQL saving unit) displays the transaction ID, issue SQL sequence number, update SQL statement, update target table name (DB name), update target specific key, SQL execution result (success) (Or failure) and an update SQL statement registration request including a transaction state of “1” indicating that the work is in progress is transmitted to the DB server 9 (step S47). The DB server 9 receives the update SQL registration request as described above, and registers it in the issued SQL log table 93. Then, the DB server 9 returns the processing result to the DB access component b. This update process is immediately committed (COMMIT).

  When the DB access component b receives the processing result indicating the normal end from the DB server 9, the DB access component b notifies the user application b of the normal processing end (step S49). The user application b receives a normal process end notification from the DB access component b (step S51).

  Then, the ROLLBACK unit 625 of the user application b requests the DB access component b to perform a DB transaction rollback (ROLLBACK) (step S53). The ROLLBACK unit 5171 in the business transaction control component 517 of the DB access component b receives the DB transaction rollback request from the user application b, and performs the DB transaction rollback (step S55). That is, it requests the DB server 9 to return the user DB updated in step S45 to the original state. The DB server 9 returns the update of the user DB to the original state in response to a rollback request from the ROLLBACK unit 5171 in the business transaction control component 517 of the DB access component b. The DB server 9 transmits a rollback completion notification to the DB access component b. Upon receiving the rollback completion notification from the DB server 9, the DB access component b further transmits a rollback completion notification to the user application b.

  When receiving the rollback completion notification from the DB access component b, the user application b notifies the calling user application a of normal termination (step S57). The calling user application a receives a normal end notification from the calling user application b (step S59). The processing shifts to the processing in FIG.

  When the user application “a” needs to request the user application “c” of the AP server C in response to the business process request, the user application “a” sends a call to the user application “c” including necessary data and transaction ID to the AP server C. (Step S61). The user application c of the AP server C receives the user application c call including necessary data and the transaction ID from the AP server A, and stores the transaction ID in a storage device such as a main memory (step S63).

  Then, the user application c performs a predetermined business process (Step S65). When it is necessary to update the data held in the user DBA or the user DBB managed by the DB server 9 in this predetermined business process, a DB update request including a transaction ID is output to the DB access component c (step S67).

  When the DB access component c receives a DB update request including a transaction ID from the user application c (step S69), the user DB access component update SQL issuance for the DB access component c (DB to be updated (also called a table)) is issued. Part) transmits to the DB server 9 a request for confirming whether or not there is an in-process process for the same table and the same record in order to confirm that no exclusion error occurs (step S71). Specifically, the DB server is configured to search the issued SQL log table 93 using the condition clause for specifying the update target table name and the update target record among the data necessary for configuring the update SQL statement. 9 The DB server 9 searches the update target table and the update target specifying key in the issued SQL log table 93 based on the received update target table name and the conditional clause for specifying the update target record. Based on this search result, it is determined whether or not there is another transaction that is updating the same table and the same record, and if there is, it is determined whether the transaction state is “1” indicating that the transaction is in progress. The determination may be made by the DB server 9 or the DB access component c.

  If there is another transaction that is trying to update the same table and the same record, and the transaction status indicates that the transaction is in progress, no further processing is performed due to an exclusive error, and the DB The access component c notifies the user application c of an exclusion error. The user application c notifies the calling user application a of the error.

  On the other hand, if there is no other transaction for which the same table and the same record are to be updated, or the transaction state indicates a completed state even if it exists, the DB access component c (user DB access component) The update SQL issuing unit) further requests the DB server 9 to search the issued SQL log table 93 with the received transaction ID. The DB server 9 receives the request including the transaction ID, searches the issue SQL log table 93, and extracts the issue SQL sequence number of the corresponding record. For example, the DB server 9 transmits the largest number among the issued SQL sequence numbers to the DB access component c. All the issued SQL sequence numbers extracted may be transmitted to the DB access component c. For example, when the DB access component c receives the largest number of the issued SQL sequence numbers, the DB accessed component c increments the largest issued SQL sequence number by 1 and issues the issued SQL sequence number used this time (step S73).

  The DB access component c (user DB access component update SQL issuing unit) issues an update SQL sentence based on the DB update request to the DB server 9 (step S75). When the DB server 9 receives the update SQL statement from the DB access component c, the DB server 9 performs a temporary update of the user DB based on the update SQL statement. An error may occur at this time. When an error occurs, the DB access component c is notified to that effect.

  On the other hand, when the update process using the update SQL statement is normally completed, the DB server 9 notifies the DB access component c to that effect. Then, the DB access component c (user DB access component issuance SQL saving unit) displays the transaction ID, issue SQL sequence number, update SQL statement, update target table name (DB name), update target specific key, SQL execution result (success) Or an update SQL statement registration request including a transaction status of “1” indicating that the work is in progress is transmitted to the DB server 9 (step S77). The DB server 9 receives the update SQL registration request as described above, and registers it in the issued SQL log table 93. Then, the DB server 9 returns the processing result to the DB access component c. This update process is immediately committed (COMMIT).

  When the DB access component c receives the processing result indicating the normal end from the DB server 9, the DB access component c notifies the user application c of the normal processing end (step S79). The user application c receives a normal process end notification from the DB access component c (step S81).

  Then, the ROLLBACK unit of the user application c requests the DB access component c to perform a DB transaction rollback (ROLLBACK) (step S83). The ROLLBACK unit in the business transaction control component of the DB access component c receives the DB transaction rollback request from the user application c, and executes the DB transaction rollback (step S85). In other words, the DB server 9 is requested to cancel the update of the user DB executed by the DB server 9 in step S75 and restore the original state. In response to the rollback request from the ROLLBACK unit in the business transaction control component of the DB access component c, the DB server 9 cancels the update of the user DB and returns it to the original state. The DB server 9 transmits a rollback completion notification to the DB access component c. Upon receiving the rollback completion notification from the DB server 9, the DB access component c further transmits a rollback completion notification to the user application c.

  When receiving the rollback completion notification from the DB access component c, the user application c notifies the caller user application a of normal termination (step S87). The calling user application a receives a normal end notification from the calling user application c (step S89). The processing shifts to the processing in FIG.

  The user application a performs predetermined business processing based on the processing results so far (step S91). When the predetermined business process is completed, the ROLLBACK unit of the user application a requests the DB access component a for DB transaction rollback (ROLLBACK) (step S93). The ROLLBACK unit 6191 in the business transaction control component 619 of the DB access component a receives the request for the DB transaction rollback from the user application a, and performs the DB transaction rollback (step S95). That is, the DB server 9 is requested to cancel the update of the user DB executed by the DB server 9 in step S23 and restore the original state. In response to the rollback request from the ROLLBACK unit 6191 in the business transaction control component 619 of the DB access component a, the DB server 9 cancels the update of the user DB and returns it to the original state. The DB server 9 transmits a rollback completion notification to the DB access component a. Upon receiving the rollback completion notification from the DB server 9, the DB access component a further transmits a rollback completion notification to the user application a.

  When the user application a receives a rollback completion notification from the DB access component a, the user application a causes the batch COMMIT processing call unit 615 of the user application a to output a DB batch update request including a transaction ID related to the processing to the DB access component a ( Step S97). The DB batch update unit 6171 of the update SQL batch execution component 617 of the DB access component a receives a DB batch update request including a transaction ID from the user application a (step S99), and issues an issued SQL log table to the DB server 9. The update SQL statement corresponding to the transaction ID is requested from 93 in the order of the issued SQL sequence numbers. The DB server 9 receives, from the DB access component a, a request for reading the update SQL statement corresponding to the transaction ID from the issue SQL log table 93 in the order of the issue SQL sequence number, and the update corresponding to the transaction ID is issued from the issue SQL log table 93. The SQL statements are read in the order of the issued SQL sequence numbers and transmitted to the DB access component a. The DB batch update unit 6171 of the update SQL batch execution component 617 of the DB access component a receives update SQL statements corresponding to the transaction ID from the DB server 9 in the order of the issued SQL sequence numbers (step S101).

  Then, the DB batch update unit 6171 in the update SQL batch execution component 617 of the DB access component a transmits the received update SQL statements to the DB server 9 in the order of the issued SQL sequence numbers, and requests execution of the update SQL statements ( Step S103). The DB server 9 receives update SQL statements from the DB access component a in the order of the issued SQL sequence numbers, and performs update processing on the user DBA or the user DBB according to the update SQL statements. The result of the update process is notified from the DB server 9 to the DB access component a.

  If the result of the update process is received and the result of the update process ends normally, the DB batch update unit 6171 in the update SQL batch execution part 617 of the DB access part a sends the transaction ID related to the process to the DB server 9. A request is made to change the transaction state corresponding to to completion of processing (step S105). When the DB server 9 receives the request, the DB server 9 registers the transaction state corresponding to the transaction ID related to the process in the issued SQL log table 93 so as to have a value “0” indicating the process completion. The DB server 9 notifies the processing result to the DB access component a.

  If the processing result is received and the processing result is a normal end, the COMMIT unit 6193 in the business transaction control component 619 of the DB access component a performs a DB transaction commit (COMMIT) for each update SQL statement in step S103, and the DB server 9 (Step S107). When the DB server 9 receives the DB transaction commit from the DB access component a, the DB server 9 confirms the update for the user DBA and the user DBB. Then, the DB server 9 notifies the DB access component a of the end of processing.

  When receiving the process end notification from the DB server 9, the DB access component a notifies the user application a of the end of the process (step S109). When the user application a receives a process end notification from the DB access component a (step S111), the user application a transmits a response to the business process request to the requesting client terminal 3 (step S113).

  When the processing is normally completed, the above processing is performed. If all the processing is completed normally, the processing will be heavier by the amount registered in the ROLLBACK (rollback) of the updated SQL statement and the issued SQL log table 93. However, as described below, if the processing does not end normally There are significant benefits.

  Next, a case where an error occurs after the user application c is called will be described with reference to FIGS. 17 and 18. Specifically, the processing after the terminal B will be described.

  First, when the user application a has to request the user application c of the AP server C in response to the business process request, the user application c calls the user application c including the necessary data and transaction ID to the AP server C. Transmit (step S121). The user application c of the AP server C receives the user application c call including necessary data and transaction ID from the AP server A, and stores the transaction ID in a storage device such as a main memory (step S123).

  Then, the user application c performs a predetermined business process (step S125). When it is necessary to update the data held in the user DBA or the user DBB managed by the DB server 9 in this predetermined business process, a DB update request including a transaction ID is output to the DB access component c (step S127). The process of the user application c shifts to the process of FIG.

  When the DB access component c receives a DB update request including a transaction ID from the user application c (step S129), the user DB access component update SQL issue for the DB access component c (DB to be updated (also referred to as a table)) is issued. In order to confirm that an exclusive error does not occur, the part) transmits a request to the DB server 9 to confirm whether or not there is an in-process process for the same table and the same record (step S131). Specifically, the DB server is configured to search the issued SQL log table 93 using the condition clause for specifying the update target table name and the update target record among the data necessary for configuring the update SQL statement. 9 The DB server 9 searches the update target table and the update target specifying key in the issued SQL log table 93 based on the received update target table name and the conditional clause for specifying the update target record. Based on this search result, it is determined whether or not there is another transaction that is updating the same table and the same record, and if there is, it is determined whether the transaction state is “1” indicating that the transaction is in progress. The determination may be made by the DB server 9 or the DB access component c.

  In step S131, if there is another transaction that is updating the same table and the same record and the transaction state is “1” indicating that the transaction is in progress (step S133: Yes route), the DB access component c is The exclusive error is notified to the user application c. When the user application c receives an exclusion error from the DB access component c (step S135), the user application c cannot perform any further processing. The processing shifts to the processing in FIG.

  On the other hand, if there is no other transaction that is attempting to update the same table and the same record, or the transaction state indicates a completed state even if it exists (step S133: No route), DB access The component c (user DB access component update SQL issuing unit) further requests the DB server 9 to search the issued SQL log table 93 with the received transaction ID. The DB server 9 receives the request including the transaction ID, searches the issue SQL log table 93, and extracts the issue SQL sequence number of the corresponding record. For example, the DB server 9 transmits the largest number among the issued SQL sequence numbers to the DB access component c. All the issued SQL sequence numbers extracted may be output to the DB access component c. For example, when the DB access component c (user DB access component update SQL issuing unit) receives the largest number of the issued SQL sequence numbers, the largest issued SQL sequence number is incremented by 1, and the issued SQL sequence number used this time Is issued (step S137).

  Then, the DB access component c issues an update SQL sentence based on the DB update request to the DB server 9 (step S139). When the DB server 9 receives the update SQL statement from the DB access component c, the DB server 9 attempts to perform a temporary update of the user DB based on the update SQL statement. The processing shifts to the processing in FIG.

  Shifting to the description of the processing in FIG. 18, the DB server 9 notifies the DB access component c of the result of the update processing by the update SQL statement. The DB access component c (user DB access component update SQL issuing unit) receives the result of the update process by the update SQL statement from the DB server 9, and determines whether an error has occurred (step S141). If an error has occurred, the DB access component c outputs the error to the user application c (step S142). When the user application c receives an error from the DB access component c (step S143), the user application c proceeds to step S153. That is, ROLLBACK (rollback) is executed just in case.

  On the other hand, the DB access component c (the user DB access component issuance SQL saving unit) is used for analysis or the like after the occurrence of an error or after step S142, in order to use the transaction ID, issue SQL sequence number, update SQL, etc. An update SQL statement registration request including a statement, an update target table name (DB name), an update target specifying key, an SQL execution result (success or failure), and a transaction status of “1” indicating that the work is in progress is sent to the DB server. 9 (step S145). The DB server 9 receives the update SQL registration request as described above, and registers it in the issued SQL log table 93. Then, the DB server 9 returns the processing result to the DB access component c.

  When the DB access component c (user DB access component issuance SQL saving unit) receives the processing result from the DB server 9, the DB access component c determines whether the processing result indicates an error occurrence (step S147). If no error has occurred including step S141, the process is the same as the normal end, and the process proceeds to the process in FIG. If step S145 is successful, an immediate commit (COMMIT) is performed. On the other hand, if an error has occurred in step S139 but no error has occurred in step S145, the DB access component c has successfully completed the process in step S145 for the user application c, although not shown in the figure. Notify that. In the user application c, the process proceeds to step S153.

  On the other hand, when an error occurs in step S145, the DB access component c (user DB access component issuance SQL saving unit) outputs an error to the user application c (step S149). The user application c receives an error from the DB access component c (step S151). Then, after step S151 or step S143, the ROLLBACK unit of the user application c requests a DB transaction rollback (ROLLBACK) from the DB access component c (step S153). Even in the case where the update process has failed in step S139, step S153 is executed just in case.

  The ROLLBACK unit in the business transaction control component of the DB access component c receives the DB transaction rollback request from the user application c, and executes the DB transaction rollback (step S155). That is, the DB server 9 is requested to cancel the update of the user DB executed by the DB server 9 in step S139 and restore the original state. In response to a rollback request from the ROLLBACK unit in the business transaction control component of the DB access component c, the DB server 9 cancels the update of the user DB and returns it to the original state. The DB server 9 transmits a rollback completion notification to the DB access component c. Upon receiving the rollback completion notification from the DB server 9, the DB access component c further transmits a rollback completion notification to the user application c.

  In this way, even if an error occurs at any stage, the user DBA and the user DBB are restored to the original state, so there is no need to prepare an individual cancellation process and There is no need to execute.

  When receiving the rollback completion notification from the DB access component c, the user application c transmits an error notification to the calling user application a (step S157). When the user application a receives an error notification from the user application c (step S159), the user application a cannot perform the following business process. Accordingly, the ROLLBACK unit of the user application a requests the DB access component a to perform a DB transaction rollback (ROLLBACK) (step S161). The ROLLBACK unit 6191 in the business transaction control component 619 of the DB access component a receives the request for the DB transaction rollback from the user application a, and performs the DB transaction rollback (step S163). That is, the DB server 9 is requested to cancel the update of the user DB executed by the DB server 9 in step S23 and restore the original state. In response to the rollback request from the ROLLBACK unit 6191 in the business transaction control component 619 of the DB access component a, the DB server 9 cancels the update of the user DB and returns it to the original state. The DB server 9 transmits a rollback completion notification to the DB access component a. Upon receiving the rollback completion notification from the DB server 9, the DB access component a further transmits a rollback completion notification to the user application a.

  Furthermore, for example, the collective COMMIT process calling unit 615 of the user application a outputs a DB update cancel request including the transaction ID to the DB access component a (step S165). When the update SQL batch execution component 617 of the DB access component a receives the DB update cancel request including the transaction ID (step S167), the transaction status of the record relating to the transaction ID in the issued SQL log table 93 is sent to the DB server 9. Registration is requested so that becomes a value “0” indicating the completion of processing (step S169). In response to the request, the DB server 9 registers in the issued SQL log table 93 so that the transaction state of the record relating to the transaction ID becomes a value “0” indicating the completion of processing. This processing is also immediate COMMIT. Then, the DB access component a notifies the user application a of the completion of processing. In the issue SQL log table 93, if an error occurs in the update process according to the update SQL statement, that is registered in the SQL execution result, but if an error occurs in the other part, At this stage, it may be registered in the issued SQL log table 93. By executing this step, an exclusion error does not occur even if an update to the same table and the same record occurs in another transaction.

  The user application a receives the completion of processing from the DB access component a, and sends a notification to the effect that an error has occurred in response to the business process request to the client terminal 3 that is the request source (step S171).

  In this way, the update process using the update SQL statement is temporarily restored by rollback (ROLLBACK), so even if an error occurs in another process part, there is no need to perform a complicated cancel process, and the user DB It becomes possible to shift to other transaction processing without leaving an influence on the transaction.

  Although one embodiment of the present invention has been described above, the present invention is not limited to this. For example, in the example described above, the transaction status is managed in the issue SQL log table 93. If the transaction status is “in progress”, a record is registered in the issue SQL log table 93 in advance. If “processing complete”, the record may be deleted from the issued SQL table 93. In this case, since no record remains, it becomes impossible to analyze an error later.

  Moreover, the functional block configuration shown in FIGS. 1 and 2 is an example, and may not necessarily match the actual program configuration.

  Further, regarding the processing flow, the processing order may be changed as long as the processing result does not change. For example, in the processing flow described above, the rollback processing for the AP server A is performed after calling another user application, but every time processing completion is notified from the DB access component a. Rollback may be performed.

  As for the AP server, client terminal, and DB server, as shown in FIG. A unit 2507, a drive device 2513 for a removable disk 2511, an input device 2515, and a communication control unit 2517 for connecting to a network are connected by a bus 2519. Application programs including the OS and the Web browser are stored in the HDD 2505, and are read from the HDD 2505 to the memory 2501 when executed by the CPU 2503. If necessary, the CPU 2503 controls the display control unit 2507, the communication control unit 2517, and the drive device 2513 to perform necessary operations. Further, data in the middle of processing is stored in the memory 2501 and stored in the HDD 2505 if necessary. Such a computer realizes various functions as described above by organically cooperating hardware such as the CPU 2503 and the memory 2501 described above with the OS and necessary application programs.

(Appendix 1)
A program for ensuring data consistency in a plurality of database update processes executed in response to one business process request by a plurality of related business process programs,
In a computer that executes the business program,
Issuing a unique transaction ID in response to a business processing request from a business processing client;
In response to a first database update request from any one of the business process programs that process the business process request, a first update instruction based on the first database update request is output to the database and corresponds to the transaction ID Processing to register the first update instruction in the issuance instruction log table, and to output a cancel instruction of the first update instruction to the database regardless of success or failure of the update process by the first update instruction;
When the processing for the business process request is normally completed, the first update command registered in the issued command log table corresponding to the transaction ID issued for the business process request is sent to the first update command. A confirmation step of outputting to the database a commit instruction for outputting to the database and further confirming an update by the first update instruction;
A program for running

(Appendix 2)
When the process for the business process request is not completed normally, the update command registered in the issued command log table corresponding to the transaction ID issued for the business process request is discarded, or The program according to appendix 1, for causing the computer to further execute an error processing step of executing at least one of registration of data for invalidating the update instruction in the issued instruction log table.

(Appendix 3)
In the first processing step, before outputting an update command to the database, it is determined whether an update command for the same table and the same record is effectively held with reference to the issued command log table,
In the error processing step, when it is determined by the processing step that the database update request for the same table and the same record is effectively held in the issued command log table, the processing for the business processing request is normally completed. The update command registered in the issued command log table corresponding to the transaction ID issued in response to the business process request is discarded, or the data that invalidates the update command is issued. Execute at least one of registration in the instruction log table.
The program described in Appendix 2.

(Appendix 4)
A method for ensuring data consistency in a plurality of database update processes executed in response to one business process request by a plurality of related business process programs,
A computer that executes the business program,
Issuing a unique transaction ID in response to a business processing request from a business processing client;
In response to a first database update request from any one of the business process programs that process the business process request, a first update instruction based on the first database update request is output to the database and corresponds to the transaction ID Processing to register the first update instruction in the issuance instruction log table, and to output a cancel instruction of the first update instruction to the database regardless of success or failure of the update process by the first update instruction;
When the processing for the business process request is normally completed, the first update command registered in the issued command log table corresponding to the transaction ID issued for the business process request is sent to the first update command. A confirmation step of outputting to the database a commit instruction for outputting to the database and further confirming an update by the first update instruction;
How to run.

(Appendix 5)
A computer system that performs processing for ensuring data consistency in a plurality of database update processing executed in response to one business processing request by a plurality of related business processing programs,
A means for issuing a unique transaction ID in response to a business processing request from a business processing client;
In response to a first database update request from any one of the business process programs that process the business process request, a first update instruction based on the first database update request is output to the database and corresponds to the transaction ID Processing means for registering the first update instruction in an issuance instruction log table and outputting a cancel instruction for the first update instruction to the database regardless of whether or not the update process by the first update instruction is successful;
When the processing for the business process request is normally completed, the first update registered in the issue command log table corresponding to the transaction ID issued for the business process request is stored in the database. And a committing means for outputting to the database a commit command for confirming an update by the first update command;
A computer system.

It is a system outline figure in an embodiment of the invention. It is a functional block diagram of DB access parts. It is a figure for demonstrating the data structure of an issue SQL log table. It is the schematic diagram 1 for demonstrating the process of embodiment of this invention. It is the schematic diagram 2 for demonstrating the process of embodiment of this invention. It is the schematic diagram 3 for demonstrating the process of embodiment of this invention. It is the schematic diagram 4 for demonstrating the process of embodiment of this invention. It is the schematic diagram 5 for demonstrating the process of embodiment of this invention. It is the schematic diagram 6 for demonstrating the process of embodiment of this invention. FIG. 7 is a schematic diagram for explaining the processing according to the embodiment of the present invention. It is the schematic diagram 8 for demonstrating the process of embodiment of this invention. It is the schematic diagram 9 for demonstrating the process of embodiment of this invention. It is a figure which shows the processing flow of the detailed process in embodiment of this invention. It is a figure which shows the processing flow of the detailed process in embodiment of this invention. It is a figure which shows the processing flow of the detailed process in embodiment of this invention. It is a figure which shows the processing flow of the detailed process in embodiment of this invention. It is a figure which shows the processing flow of the detailed process in embodiment of this invention. It is a figure which shows the processing flow of the detailed process in embodiment of this invention. It is a functional block diagram of a computer.

Explanation of symbols

1, 7 Network 3 Client terminal 5 AP server 9 DB server 93 Issued SQL log table

Claims (5)

A program for ensuring data consistency in a plurality of database update processes executed in response to one business process request by a plurality of related business process programs,
In a computer that executes the business program,
Issuing a unique transaction ID in response to a business processing request from a business processing client;
In response to a first database update request from any one of the business process programs that process the business process request, a first update instruction based on the first database update request is output to the database and corresponds to the transaction ID Processing to register the first update instruction in the issuance instruction log table, and to output a cancel instruction of the first update instruction to the database regardless of success or failure of the update process by the first update instruction;
When the processing for the business process request is normally completed, the first update command registered in the issued command log table corresponding to the transaction ID issued for the business process request is sent to the first update command. A confirmation step of outputting to the database a commit instruction for outputting to the database and further confirming an update by the first update instruction;
A program for running When the process for the business process request is not completed normally, the update command registered in the issued command log table corresponding to the transaction ID issued for the business process request is discarded, or The program according to claim 1, further causing the computer to execute an error processing step of executing at least one of registration of data for invalidating the update instruction in the issued instruction log table. In the first processing step, before outputting an update command to the database, it is determined whether an update command for the same table and the same record is effectively held with reference to the issued command log table,
In the error processing step, when it is determined by the processing step that the database update request for the same table and the same record is effectively held in the issued command log table, the processing for the business processing request is normally completed. The update command registered in the issued command log table corresponding to the transaction ID issued in response to the business process request is discarded, or the data that invalidates the update command is issued. Execute at least one of registration in the instruction log table.
The program according to claim 2. A method for ensuring data consistency in a plurality of database update processes executed in response to one business process request by a plurality of related business process programs,
A computer that executes the business program,
Issuing a unique transaction ID in response to a business processing request from a business processing client;
In response to a first database update request from any one of the business process programs that process the business process request, a first update instruction based on the first database update request is output to the database and corresponds to the transaction ID Processing to register the first update instruction in the issuance instruction log table, and to output a cancel instruction of the first update instruction to the database regardless of success or failure of the update process by the first update instruction;
When the processing for the business process request is normally completed, the first update command registered in the issued command log table corresponding to the transaction ID issued for the business process request is sent to the first update command. A confirmation step of outputting to the database a commit instruction for outputting to the database and further confirming an update by the first update instruction;
How to run. A computer system that performs processing for ensuring data consistency in a plurality of database update processing executed in response to one business processing request by a plurality of related business processing programs,
A means for issuing a unique transaction ID in response to a business processing request from a business processing client;
In response to a first database update request from any one of the business process programs that process the business process request, a first update instruction based on the first database update request is output to the database and corresponds to the transaction ID Processing means for registering the first update instruction in the issued instruction log table and outputting a cancellation request for the first update instruction to the database regardless of success or failure of the update process by the first update instruction;
When the processing for the business process request is normally completed, the first update command registered in the issued command log table corresponding to the transaction ID issued for the business process request is sent to the first update command. Confirming means for outputting to the database a commit instruction for outputting to the database and further confirming the update by the first update instruction;
A computer system.

Images