JP3253321B2 - Synchronization confirmation processing method for database access - Google Patents

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 method for a database access for confirming the synchronization between a database management system (DBMS) and an application program when the access to a database is temporarily suspended after the access is temporarily suspended. About.

[0002]

2. Description of the Related Art In a conventional DBMS, when data is updated, an update request sent from an application program is sequentially received and data is temporarily updated. Thereafter, when a commit command is received from the application program, the actual update of the update request received earlier is executed. With this method,
If a failure occurs during the data update processing, the provisional update is canceled (rolled back) to synchronize the DBMS with the application program. References: 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 before the application program receives the commit completion notice after sending the commit request, the application program cannot confirm that the actual update has been executed. . Therefore, it is necessary to confirm the data update after the recovery from the failure and synchronize the DBMS and the application program.

[0004] However, in the current DBMS, a DBMS in which the completion of a transaction can be confirmed from an application program and a transaction in which the transaction is completed can be confirmed .
What from the application program about completion confirmation
If no other measures are taken, the completion of the transaction
There are DBMSs that cannot be recognized . FIG. 3 shows a transaction completion confirmation method in a commercially available DBMS. In a DBMS that does not have a function of confirming the completion of a transaction, there is a problem that a reliable system cannot be constructed because a transaction cannot be sufficiently guaranteed. Also, when trying to build a network environment using various types of DBMS, application /
The program and the DBMS cannot be synchronized, which hinders the improvement of the portability of the application program for accessing the database.

[0005]

As described above, the conventional D
In BMS, the synchronization confirmation method after failure recovery cannot be shared, so that the portability of the application program is impaired in the fault tolerance during database access. There is a problem that the portability of the program is impaired.

SUMMARY OF THE INVENTION It is an object of the present invention to enable a DBMS to perform synchronization confirmation after recovery from a failure by a common method.

[0007]

According to the present invention, synchronization is confirmed from an application program to a heterogeneous DBMS by a common method.

FIG. 2 shows a flowchart for confirming synchronization in the case of the present invention. Synchronization confirmation is performed for each transaction. A request from the application program is received (S1). If the received request is a transaction start request (S2), an identifier is assigned to each transaction (S3), and the transaction identifier is stored in a memory (S4). .

When a commit request is issued from the application program (S5), each application program
The transaction identifier is written in a transaction log table prepared in the database for each program (S6). If not a commit request, refer to data
Data operation execution is performed (S7). After the write processing to the transaction log table is completed, a commit request is made again 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 transaction is completed (after the completion of the commit), the contents of the transaction log table are stored in the DBMS. Therefore, information such as a transaction identifier remains in the table. Therefore, the contents of the memory and the contents of the transaction log table match.

On the other hand, if a failure occurs before the transaction is completed, such information is lost by the rollback processing. Therefore, a mismatch occurs 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 various functions are realized using only the functions of generating and writing tables in the database, which are the basic functions of the DBMS,
Applicable to BMS.

[0014]

FIG. 1 is a block diagram showing an embodiment of the present invention. The application program 1 sends an SQL statement for updating data to the control device 3 via the line 12. The control device 3 determines whether the sent SQL statement is the first SQL statement after the last commit, the second or subsequent SQL statement,
Determine whether the statement is a commit request statement.

In the case of the first SQL statement, the control unit 3
4 and notifies the transaction identifier generation device 4 of the transaction start.
Sends an SQL statement to BMS7.

The transaction identifier generating device 4 has a line 1
Reference is made to the history of the transaction identifier stored in the memory 2 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 an SQL statement to the DBMS 7 via the line 16.
The DBMS 7 that has received the SQL statement operates the user table 9 through the line 21.

In the case of a commit request statement, the control unit 3
Transaction commitment controller 5 through 5
To notify the commit request. Upon receiving the request, the transaction commitment control device 5 refers to the transaction identifier via the line 18 and
An SQL statement is sent to S7. DB that received the SQL statement
The MS 7 writes the transaction identifier to the transaction log table 10 via the 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 that has received the write end signal sends a commit request to the DBMS 7 via the line 19. D that received the commit request
The BMS 7 performs a commit on the database 8 through the lines 21 and 22.

When the database operation processing is interrupted due to an abnormality or the like, the DBMS detects a failure, and rolls back transactions that have not been committed through lines 21 and 22. When a rollback is performed, the user table 9 and the transaction log are kept up to the state immediately after the most recent commit.
Table 10 is restored.

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

Further, the application program 1
Sends a request for confirmation of the completed transaction to the controller 3 via the line 12. When receiving the confirmation request for the completed transaction, the control device 3 sends a request for searching the transaction log table 10 to the confirmation device 6 via 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 via the line 20. When receiving the transaction log table 10 search request, the DBMS 7 detects the transaction log table 10 via a line 22 and notifies the checking device 6 of the search result via a line 20. The confirmation device 6 sends the transaction identifier of the completed transaction to the control device 3 via the line 17 based on the search result. 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:
If a failure occurs before the DBMS 7 writes the transaction identifier to the transaction log table 10 after the transaction identifier generation device 4 writes the transaction identifier to the memory 2, the transaction identifier stored in the memory 2 and the transaction log If the transaction identifier is different from the transaction identifier stored in the table 10 and a failure occurs in another state, the result is that they match.

[0023]

As described above, according to the present invention, there is provided a function for confirming synchronization between an application program and a DBMS after access is interrupted when trying to access a plurality of types of DBMSs as in the prior art. No DBMS
Even in this case, the synchronization can be confirmed, so that both portability of the application program and securing of fault tolerance can be achieved.

[Brief description of the drawings]

FIG. 1 is a block diagram showing a configuration of a synchronization confirmation system between 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 commercially available DBMS.

[Explanation of symbols]

 DESCRIPTION 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)

(57) [Claims] A method for confirming synchronization between an application program and a database management system (DBMS) for a plurality of types of databases, and recognizes that a request from the application program is a transaction start request. And a function for assigning and retaining a transaction identifier, and identifying that the request from the application program is a transaction end request, and recording the retained transaction identifier in a transaction log table existing under the DBMS. And a function that allows the application program to refer to the stored transaction identifier and transaction log table. When the transaction starts, the transaction identifier is stored in the memory. When the transaction ends, the transaction identifier in memory is recorded in the transaction log table. If the processing is interrupted during the transaction processing, the application program stores the transaction identifier and transaction log table synchronization confirmation processing method for the identifier stored database access, wherein ginseng stealth Rukoto.