JPH0520150A - Synchronization confirmation processing system for data base access - Google Patents

Abstract

PURPOSE:To execute the synchronization confirmation after recovery of a fault by a comma method by constituting the system so that a transaction identifier can be referred to. CONSTITUTION:In the case a request from an application program l is received, and the received request is a start request of a transaction, a transaction identifier generating device 4 gives an identifier to each transaction, and holds a transaction identifier in a memory 2. When a request of a commitment is outputted from the application program 1, the transaction identifier is written in a transaction log table 10 prepared in a data base at every application program, and unless it is the commitment request, a data reference and a data operation are executed. After a write processing to the transaction log table 10 is finished, the commitment request is executed again to a data base management system(DBMS) 7. Subsequently, whether the processing is finished or not is checked.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a synchronization confirmation processing system for database access for confirming the synchronization between a database management system (DBMS) and an application program when access is resumed after temporary interruption of access to the database. Regarding

[0002]

2. Description of the Related Art In a conventional DBMS, when data is updated, update requests sent from an application program are sequentially received and data is temporarily updated. After that, when the commit command is received from the application program, the actual update of the previously received update request is executed. By this method,
When a failure occurs during the data update process, the temporary update is canceled (rolled back) to synchronize the DBMS and the application program. Reference: ORACLE Database Administrator's Guide Ver.6
(1990), and INGRES Database Manual Ver.2 (1
989).

However, in such a system, if a failure occurs after the application program sends the commit request and before the commit completion notification is received, the application program cannot confirm that the actual update has been executed. .. Therefore, it is necessary to confirm the data update after the failure recovery and synchronize the DBMS side and the application program side.

However, in the current DBMS, some DBMS are capable of confirming the transaction completion confirmation from the application program and some are not. FIG. 3 shows a transaction completion confirmation method in a commercial DBMS. In a DBMS that does not have the function of confirming the transaction completion, the transaction cannot be sufficiently guaranteed, so that there is a problem that a reliable system cannot be constructed. Also, when attempting to build a network environment using various types of DBMS, it is not possible to synchronize the application program and the DBMS by a common method, which improves the portability of the application program for database access. It is an obstacle.

[0005]

DISCLOSURE OF THE INVENTION Problems to be Solved by the Invention
In BMS, since the synchronization confirmation method after failure recovery cannot be shared, failure resistance at the time of database access is impaired in order to ensure portability of application programs. There is a problem that the portability of the program is impaired.

An object of the present invention is to make it possible to perform synchronization confirmation after failure recovery in a DBMS by a common method.

[0007]

In the present invention, synchronization confirmation is performed from an application program to a heterogeneous DBMS by a common method.

FIG. 2 shows a flow chart for confirmation of synchronization in the case of the present invention. The synchronization confirmation is performed in transaction units. A request from an application program is accepted (S1), and if the accepted request is a transaction start request (S2), an identifier is assigned to each transaction (S3) and the transaction identifier is stored in memory (S4). ..

When a commit request is issued from the application program (S5), each application
The transaction identifier is written in the transaction log table prepared in the database for each program (S6). Data reference if not a commit request
Data operation is executed (S7). After the writing process to the transaction log table is completed, a commit request is again made to the DBMS (S8). Then, it is checked whether or not the processing is completed (S9).

[0010]

By writing the transaction identifier in the memory and the transaction log table in such a flow, if a failure occurs after the completion of the transaction (after the completion of the commit), the contents of the transaction log table are stored in the DBMS. Information such as transaction identifiers remains in the table because it is guaranteed by. Therefore, the contents of the memory and the contents of the transaction log table match.

On the other hand, when a failure occurs before the completion of the transaction, the information is lost by the rollback process. Therefore, there is a discrepancy between the contents of the memory and the contents of the transaction log table.

Therefore, it is possible for the application program to confirm the transaction execution by referring to the contents of the memory and the contents of the transaction log table after restarting from the failure.

In the case of the present invention, since it is realized by using only the basic function of the DBMS, that is, the function of generating and writing the table in the database, various D
Applicable to BMS.

[0014]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS FIG. 1 shows a block diagram of an embodiment of the present invention. The application program 1 sends a SQL statement for updating data to the control device 3 through the line 12. The control device 3 determines whether the sent SQL statement is the first SQL statement after the previous commit or the second and subsequent SQL statements.
Determine if it is a commit request statement.

In the case of the first SQL statement, the control unit 3 uses the line 1
A transaction start notification is sent to the transaction identifier generation device 4 through D4 and D is sent through line 16.
The SQL sentence is sent to the BMS 7.

The transaction identifier generator 4 is line 1
The transaction identifier history stored in the memory 2 is referenced through 3, the identifier is assigned to the start transaction, and the transaction identifier is written into the memory 2 through the line 13.

In the case of the second and subsequent SQL statements, the control unit 3
Sends the SQL statement to DBMS 7 via line 16.
The DBMS 7 receiving the SQL statement operates the user table 9 through the line 21.

In the case of the commit request statement, the control device 3 uses the line 1
Transaction commitment controller 5 through 5
Commit request notification to. Upon receiving the request, the transaction commitment control device 5 refers to the transaction identifier through the line 18 and the DBM through the line 19.
The SQL sentence is sent to S7. DB that received the SQL statement
The MS 7 writes the transaction identifier to the transaction log table 10 via line 22.
The DBMS 7 sends a write end signal to the transaction commitment control device 5 via the line 19. The transaction commitment control device 5, which has received the write end signal, sends a commit request to the DBMS 7 through the line 19. D that received the commit request
The BMS 7 executes the commit to the database 8 through the lines 21 and 22.

When the database operation processing is interrupted due to a cause such as an abnormality, the DBMS detects the failure and executes the rollback through the lines 21 and 22 for the transaction for which the commit is not completed. When a rollback is performed, the user table 9 and transaction log
The table 10 is restored.

After the database access process is interrupted, the application program 1 refers to the memory 2 through the line 11 when the process is restarted, and the application program 1
Gets the transaction identifier information of the transaction sent by.

Further, the application program 1
Sends a confirmation request of the completed transaction to the control device 3 through the line 12. When the control device 3 receives the confirmation request for the completed transaction, it sends a request for searching the transaction log table 10 to the confirmation device 6 through the line 17. When the confirmation device 6 receives the confirmation request for the completed transaction, the confirmation device 6 sends a request for searching the transaction log table 10 to the DBMS 7 through the line 20. When the DBMS 7 receives the request for searching the transaction log table 10, the DBMS 7 inspects the transaction log table 10 through the line 22 and notifies the confirmation device 6 of the search result through the line 20. The confirmation device 6 sends the transaction identifier of the completed transaction from the search result to the control device 3 through the line 17. The control device 3 sends the result sent from the confirmation device 6 to the application program 1 via the line 12.

At this time, the transaction identifier stored in the memory 2 and the transaction identifier stored in the transaction log table 10 are
When a failure occurs after the transaction identifier generation device 4 writes the transaction identifier in the memory 2 and before the DBMS 7 writes the transaction identifier in the transaction log table 10, the transaction identifier stored in the memory 2 and the transaction log -If the transaction identifier is different from that stored in the table 10 and a failure occurs in any other state, the result is that they match.

[0023]

As described above, according to the present invention, a synchronization confirmation function between the application program and the DBMS after the access is interrupted when trying to access a plurality of types of DBMS as in the prior art is provided. No DBMS
Even in this case, since it is possible to confirm synchronization, it is possible to achieve both portability and fault tolerance of the application program.

[Brief description of drawings]

FIG. 1 is a block diagram showing a configuration of a synchronization confirmation system of an application program and a DBMS.

FIG. 2 is a flowchart of a synchronization confirmation method between an application program and a DBMS.

FIG. 3 is a diagram showing a transaction completion confirmation method in a commercial DBMS.

[Explanation of symbols]

 1 Application Program 2 Memory 3 Control Device 4 Transaction Identifier Generation Device 5 Transaction Commitment Control Device 6 Confirmation Device 7 DBMS 8 Database 9 User Table 10 Transaction Log Table

Claims (1)

What is claimed is: 1. A method for confirming synchronization between an application program and a database management system (DBMS) for a plurality of types of databases, wherein a request from the application program starts a transaction. A function that recognizes a request, assigns a transaction identifier, and retains it, and identifies that the request from the application program is a transaction end request, and retains the transaction identifier under the DBMS. -A function that records in the log table and a function that allows the application program to refer to the held transaction identifier and transaction log table. If the identifier is retained in memory, the transaction identifier in memory is recorded in the transaction log table at the end of the transaction, and if the transaction is interrupted during transaction processing, the transaction identifier retained by the application program Refer to the identifier stored in the transaction log table. If the referenced identifier is different, re-execute the transaction that was being performed when the processing was interrupted. If the referenced identifier is the same, process it. Confirmation processing method for database access characterized by confirming the starting transaction when the application program is restarted by restarting the processing from the transaction next to the transaction that was being performed at the time when the transaction was suspended .